Secure Oracle PeopleSoft Suite with Fortinet Security Fabric

Oracle Cloud Infrastructure offers best-in-class security technology and operational processes to secure its enterprise cloud services. However, security in the cloud is based on a shared responsibility model. Oracle is responsible for the security of the underlying infrastructure, such as data center facilities, hardware, and software to manage cloud operations and services. Customers are responsible for securing their workloads and configuring their services and applications securely to meet their compliance obligations.

Fortinet provides enterprise-class cloud security solution that extends the Fortinet Security Fabric with native integration with Oracle Cloud Infrastructure to protect applications across on-premises data centers and cloud environments. It delivers scalable performance and brings advanced security orchestration and unified threat protection.

Companies moving or extending their Peoplesoft workloads from on-premises to Oracle Cloud Infrastructure can choose Fortinet Security Fabric cloud solution to connect and extend their data center network, as well as protect their workloads beyond Oracle Cloud native security options, without requiring significant configuration, integration, or business process changes.

This reference architecture provides recommendations for network and security design for organizations interested in extending the standard Oracle PeopleSoft application reference architecture, implementing Fortinet Security Fabric solution in a highly available configuration to provide failover protection.


This guide describes a reference architecture deploying and operating the PeopleSoft multitier application architecture, along with Fortinet’s Security Fabric solution, implementing a hub-spoke network topology for monitoring North-South and East-West traffic. In general terms, North-South traffic is the traffic flow that enters and leaves the network, while East-West traffic flow is the traffic within the network.

The hub-spoke topology is a traditional networking pattern that connects a centralized network (the hub) to multiple directed connected networks (the spokes). The traffic between these networks flows through a highly available FortiGate next-generation firewall, providing a centralized location to enforce security and traffic inspection. The hub virtual cloud network (VCN) is the central point of connectivity for both North-South and East-West traffic. Each tier of PeopleSoft architecture is deployed on its own spoke VCN, allowing microsegmentation with more layers of protection, because every packet moving between different tiers is inspected and secured.

This architecture can provide a highly scalable and modular design for connecting multiple spokes, where each spoke network represents one application’s tier, such as web, application, and database. It works in both one particular environment, such as production, test, and dev, and different infrastructures, such as regions, on-premises data center, and multicloud.

FortiAnalyzer and FortiManager are optional components that you can deploy into the same subnet of FortiGate. FortiADC provides load balancing services and forwards requests to PeopleSoft web tier.

The following diagram illustrates this reference architecture.

Description of architecture-peoplesoft-fortinet-oci.png follows
Description of the illustration architecture-peoplesoft-fortinet-oci.png

Hub-Spoke topology can be implemented through the following scenarios:

  • Using transit-routing with local peering gateways (LPG) to connect spoke VCNs with the hub VCN.
  • Individually attaching each FortiGate virtual network interface card (VNIC) into each spoke VCN.

For the VNIC attachment scenario, each spoke VCN should have a route rule to forward all traffic to the FortiGate VNIC private IP address attached to the spoke VCN.

For the LPG scenario, each spoke VCN should have a route rule to forward all traffic to the LPG. Within the LPG, you should have another route rule that forwards the traffic to the untrusted IP, or floating IP, address of FortiGate attached to the hub VCN.

Consider that FortiGate shouldn’t inspect any traffic within each VCN (destination IP within the VCN CIDR range), because Oracle Cloud Infrastructure automatically forwards all packets destined for the VCN itself to the destination IP directly through the internal Oracle Cloud subnet default gateway.

North-South Inbound Traffic

Inbound traffic which originates from either the internet or from an on-premises network connects to a public IP address hosted on the untrust or wan interface of the FortiGate firewall. The public IP address (reserved or ephemeral) is a NAT IP address managed by Oracle that is associated with a secondary private IP address within the untrust subnet on Oracle Cloud Infrastructure. The secondary private IP address (floating IP) is statically assigned to the untrust interface on FortiGate. If failover occurs, the floating IP moves to another host along with the public IP address.

After packet inspection, the inbound traffic leaves FortiGate through the trust interface. The destination address is the FortiADC virtual IP address deployed in the application tier spoke VCN. FortiADC balances the traffic between the active PeopleSoft application servers based on load balancer policies. Because this traffic is within the VCN, the packet goes directly to the destination host. The ingress traffic flows in the following pattern:

  • FortiGate hub VCN: From the FortiGate untrust VNIC to the FortiGate trust VNIC to the Oracle Cloud Infrastructure trust subnet default gateway to the LPG on the trust subnet to the application tier.
  • Application tier spoke VCN: From the LPG on the application tier subnet to the Oracle Cloud Infrastructure FortiADC subnet default gateway to the FortiADC VNIC to the PeopleSoft web servers.

For multiple environments inspected through the same firewall, you can assign multiple secondary IP addresses to both untrust and trust interfaces (VNICs). Each private IP should be used as the source address which can be mapped to one specific target application or environment in your firewall policies. Alternatively, you can set up a destination NAT policy with port forwarding in the FortiGate pointing to different virtual IPs or ports that can represent each individual destination application or environment.

North-South Outbound Traffic

Outbound traffic from the FortiGate hub VCN is routed through the internet gateway.

Outbound traffic from spoke VCNs to any destination is routed from the spoke VCN LPG to the peered LPG in the hub VCN. Once the packet reaches the hub VCN, the route associated with the LPG forwards the traffic to the FortiGate floating IP in the trust interface. From there, after inspection, FortiGate routes the packet to the untrust subnet default gateway. Based on the trust subnet route table, it continues to the internet or to on-premises through the internet gateway.

East-West Traffic

Oracle recommends segmenting networks at the VCN level instead of the subnet level to be able to inspect East-West traffic because all traffic within the VCN CIDR block is automatically routed through the internal Oracle Cloud Infrastructure subnet default gateway and this route can't be overwritten.

East-West traffic from any spoke VCN is routed from the spoke VCN LPG to the peered LPG in the hub VCN and then to the FortiGate floating IP in the trust interface. FortiGate inspects the incoming traffic, and based on the FortiGate firewall policies, it sets the destination address to either the destination host in the spoke VCN or back to the source host that sent the packet. The traffic leaves FortiGate through the trust interface and is sent through the default gateway in the trust subnet which forwards the packet to the LPG peered to the destination spoke database or application VCN.

The architecture has the following components:

  • Fortinet FortiGate Next-Generation Firewall

    Provides network and security services such as threat protection, SSL inspection, and ultra-low latency for protecting internal segments and mission-critical environments. It supports direct single root I/O virtualization (SR-IOV) for enhanced performance. FortiGate can be deployed directly from Oracle Cloud Marketplace.

  • Fortinet FortiAnalyzer

    Provides data-driven enterprise security insights with centralized network logging, analytics, and reporting.

  • Fortinet FortiManager

    Delivers single-pane-of-glass management across the network and provides real-time and historical views into network activity.

  • Fortinet FortiADC

    Balances traffic across multiple geographic regions. It dynamically rewrites content based on policy routing to ensure application and server load balancing. FortiADC also handles compression, caching, HTTP 2.0, and HTTP PageSpeed optimizations.

  • PeopleSoft web tier

    Composed of the FortiADC load balancer, PeopleSoft Web server, and ElasticSearch servers.

  • PeopleSoft application tier

    Composed of PeopleSoft application servers and PeopleSoft Process Scheduler servers.

  • PeopleSoft database tier

    Composed of Oracle Database, but not limited to Oracle Exadata Database or Oracle Database services.

  • PeopleTools client tier

    The PeopleTools client for administration activities such as development, migration, and upgrade.

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domains

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, private network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. You can segment VCNs into subnets, which can be scoped to a region or to an availability domain. Both regional subnets and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.

  • Hub VCN

    A centralized network where FortiGate must be deployed. It can provide connectivity to all Spoke VCNs, Oracle Cloud Infrastructure Services, public endpoints and clients, and on-premises data center networks. It is typically composed of the following four subnets:

    • Management subnet

      Public Subnet where primary VNIC for FortiGate is attached. It is responsible for FortiGate control plane operations and general management activity.

    • Untrust subnet

      Public Subnet containing FortiGate VNIC attachment. It acts as the gateway/endpoint for ingress traffic from the Internet or from an on-premises data center.

    • Trust subnet

      Private subnet containing FortiGate VNIC attachment. It forwards the traffic to the LPG that's attached to the Hub VCN and then to the proper Spoke VCN. It should also receive ingress packets from Spoke VCNs.

    • HA subnet

      Private subnet containing FortiGate VNIC attachment. It is dedicated for heartbeat/HA traffic.

  • Web Tier spoke VCN

    A private subnet to the PeopleSoft web tier, which is composed of FortiADC load balancers setup in HA mode, PeopleSoft web servers, and PeopleSoft elastic search servers.

  • Application Tier spoke VCN

    A private subnet to the application server hosts and PeopleSoft tool hosts.

  • Database Tier spoke VCN

    A private subnet for hosting Oracle Databases.

  • Route tables

    Virtual route tables for your VCN. They have route rules to route traffic from subnets to destinations outside the VCN, for example, to the internet, to an on-premises network or to a peered VCN. Each VCN automatically comes with a default route table that has no rules.

  • Internet gateway or NAT gateway

    Either an internet gateway or a NAT gateway is used by FortiGate to communicate with external public endpoints. FortiGate requires at least a NAT gateway deployed to access Fortinet license servers, in case an internet gateway isn’t required because of a FastConnect connection.

  • Local peering gateway

    The local peering gateway (LPG) is the component on a VCN responsible for routing traffic to a locally peered VCN within the same Oracle Cloud Infrastructure region. Each hub and spoke VCN has the LPG deployed. There’s a limit of 10 LPG attachments per VCN.

  • Service gateway

    A service gateway is required for communicating with Oracle services, such as Infrastructure, PaaS, or SaaS, from the hub VCN or on-premises network.

  • Dynamic routing gateway

    The dynamic routing gateway (DRG) is a virtual router that provides a path for private traffic between VCNs and networks outside the VCN region .

  • Virtual network interface cards (VNICs)

    The services in Oracle Cloud Infrastructure data centers have physical network interface cards (NICs). Virtual machine instances communicate using virtual NICs (VNICs) associated with the physical NICs. Each instance has a primary VNIC that’s automatically created and attached during launch and is available during the instance’s lifetime. DHCP is offered to the primary VNIC only. You can add secondary VNICs after instance launch, and static IPs should be set up for each interface.

  • Private IP addresses

    A private IPv4 address and related information for addressing an instance. Each VNIC has a primary private IP and you can add and remove secondary private IPs. The primary private IP address on an instance is attached during instance launch and doesn’t change during the instance’s lifetime. Secondary IPs should also belong to the same CIDR of the VNIC’s subnet. The secondary IP is used as a floating IP, because it can move between different VNICs on different instances within the same subnet. You can also use it as a different endpoint to host different services.

  • Public IP addresses

    The networking services define a public IPv4 address chosen by Oracle that’s mapped to a private IP .

    • Ephemeral: this address is temporary and exists for the lifetime of the instance
    • Reserved: this address is persistent and exists beyond the lifetime of the instance. It can be unassigned and reassigned to another instance.
  • Source and destination check

    Every VNIC performs the source and destination check on its network traffic. Disabling this flag enables FortiGate to handle network traffic that’s not targeted for the firewall.

  • Security list

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • Compute shape

    In Compute, the shape specifies the number of CPUs and amount of memory allocated to the instance. The Compute shape also determines the number of VNICs and maximum bandwidth available for the Compute instance.


Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

  • PeopleSoft High-Availability
    • Active-Active Server Redundancy for each PeopleSoft tier

      Each tier contains redundant instances of the PeopleSoft application servers, PeopleSoft web servers, ElasticSearch servers and PeopleSoft Process Scheduler to provide high availability.

    • Fault tolerance

      Fault tolerance is achieved by deploying the servers (node) in each tier to different Availability Domains in regions with multiple ADs. On single AD regions you deploy server nodes into different Fault Domains. All PeopleSoft instances are active and receive traffic from the load balancer

    • Redundancy in the Database Tier with RAC Database

      This tier contains database system instances. For performance and HA requirements, Oracle recommends that you use two-node Oracle Real Application Clusters (RAC) database systems or Oracle Database Exadata Cloud Service in Oracle Cloud Infrastructure.

  • FortiGate high availability

    To maintain session replication and resume communication if interrupted, deploy FortiGate in active-passive high availability mode, and disable the source and destination check on the secondary VNICs for both trust and untrust interfaces. Create a dedicated interface and subnet for high-availability or heartbeat traffic.

    Secondary IPs are used during the failover event. FortiGate makes calls to Oracle Cloud APIs to move these IPs from the primary to the secondary FortiGate host.

  • FortiADC High-Availability

    Deploy FortiADC in Active-Active-VRRP HA mode which is based on the concept of VRRP but not the VRRP protocol itself. This mode allows configuration sync and session sync, similarly to other HA modes. Enable skip source/destination check on the secondary VNICs for the internal interface.

  • VCN

    When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address range that's within the standard private IP address space.

    Select an address range that doesn’t overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or in another cloud provider) that you intend to set up private connections to.

    After you create a VCN, you can't change its address range.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

  • Security lists

    Security lists acts as a virtual firewall used to control traffic at the packet level within the network. The traffic is allowed only if any rule in any of the lists allows the traffic. By default, security rules are stateful, which is a mechanism used to indicate that you want to use connection tracking that matches that rule. Thus, the response of the traffic is tracked and automatically allowed back to the originating host, regardless of the egress rules.

    Since all traffic is inspected by FortiGate Next-Gen firewall, you don’t need to enforce strict rules through the security lists. They can be eventually used as a second barrier of protection, but this is not required . Only for managing FortiGate configuration, you create a security list to allow SSH and HTTPS traffic or any additional service that might be required. For all the remaining traffic across the Hub and Spoke VCNs that goes through the firewall, you need to modify the default security lists to allow ingress and egress traffic for all ports/protocols.

  • FortiGate firewall policies

    A firewall policy is a compartmentalized set of instructions that control the traffic flow going through the firewall. These instructions control where the traffic goes, how it’s processed, if it’s processed, and even whether it’s allowed to pass through the FortiGate. When the firewall receives a connection packet, it analyzes the packet’s source address, destination address, and service by port number. It also registers the incoming and outgoing interface. There’s also an action associated with the policy: accept or deny. If the action is accept, the policy permits communication sessions. Otherwise, the policy action blocks communication sessions.

    PeopleSoft requires policies with the following ports and protocol to be open :

    Tier Component Protocol Port
    Web tier Web server TCP/HTTPS 443 (PIA)
    Web tier Web server TCP 22 (SSH)
    Web tier Elastic search TCP 9200
    Application tier JSL TCP 9033-9040
    Database tier TNSListener TCP 1521–1522
    Client tier PeopleTools client VM TCP/UDP 10200–10205

    For East-West traffic, consider the following traffic pattern:

    Traffic Flow Component Name Protocol/Port
    Web tier and App tier JSL TCP/443
    App tier and Database tier TNSListener TCP/1521-1522
    Client tier and Web tier SSH TCP/22
    Client tier and App tier SSH TCP/22
    Client tier and App tier JOTL/JSL TCP/9033-9040
    Client tier and Database tier TCP TCP/1521-1522

    For example, you can create policies on the FortiGate trusted interface to allow traffic between web and application tiers and between application and database tiers.

    You can also create a policy with destination NAT pointing to a Virtual IP address to allow or restrict access PeopleSoft suite from specific source IP address or networks.

  • FortiGate static routes policies

    Create a static route on FortiGate for each spoke VCN (destination address/network) and set Gateway IP to the trust subnet default gateway address (first host IP address in the trust subnet CIDR).

    For outbound connection, create a static route on FortiGate for outbound traffic and set Gateway IP to the untrust subnet default gateway address (first host IP add address in the untrust subnet CIDR).

  • Oracle Cloud Infrastructure VCN route tables

    The following route tables should be created for North-South and East-West traffic inspection.

    VCN Name Destination Target Type Target Default Route Table for Subnet
    FortiGate FortiGate_Untrust-mgmt_route_table Internet Gateway <FortiGate VCN Internet Gateway> untrusted management
    FortiGate FortiGate_Trust-route_table <Web_Tier VCN CIDR> Local peering gateway <LPG-Web_Tier> N/A
    FortiGate FortiGate_Trust-route_table <Application_Tier VCN CIDR> Local peering gateway <LPG-Application_Tier> N/A
    FortiGate FortiGate_Trust-route_table <DB_Tier VCN CIDR> Local peering gateway <LPG-DB_Tier> N/A
    FortiGate FortiGate_Trust-route_table <Client_Tier VCN CIDR> Local peering gateway <LPG-Client_Tier> N/A
    FortiGate LPG-route_table Private IP <FortiGate Trust VNIC Private IP (floating IP)> N/A
    Web_Tier Default route table N/A <LPG-Web_Tier-to-Hub> N/A
    Application_Tier Default route table N/A <LPG-Application_Tier-to-Hub> N/A
    DB_Tier Default route table N/A <LPG-DB_Tier-to-Hub> N/A
    Client_Tier Default route table N/A <LPG-Client_Tier-to-Hub> N/A
  • Oracle Cloud Infrastructure VCN local peering gateways

    The following LPGs must be created to allow North-South and East-West communication

    • FortiGate VCN LPG setup
      Name Route Table Peer Advertised CIDR Cross-Tenancy
      LPG-Web-Tier LPG-route_table <Web_Tier VCN CIDR> No
      LPG-Application-Tier LPG-route_table <Application_Tier VCN CIDR> No
      LPG-DB-Tier LPG-route_table <DB_Tier VCN CIDR> No
      LPG-Client-Tier LPG-route_table <Client_Tier VCN CIDR> No
    • Web-tier VCN LPG setup
      Name Route Table Peer Advertised CIDR Cross-Tenancy
      LPG-Web-Tier-to-Hub N/A No
    • Application-tier VCN LPG setup
      Name Route Table Peer Advertised CIDR Cross-Tenancy
      LPG-Application-Tier-to-Hub N/A No
    • Database-tier VCN LPG setup
      Name Route Table Peer Advertised CIDR Cross-Tenancy
      LPG-DB-Tier-to-Hub N/A No
    • Client-tier VCN LPG setup
      Name Route Table Peer Advertised CIDR Cross-Tenancy
      LPG-Client-Tier-to-Hub N/A No
  • FortiADC Server Load Balancing

    FortiADC must be deployed within the same VCN as the Application tier in HA mode. Create session persistent cookie (layer 4) at the FortiADC to distribute the traffic between the Application tier hosts.

    FortiADC should use session state with HTTP headers and cookies to ensure that users and servers remain persistent. Thus, you should create a persistence type “Insert Cookie” on FortiADC to insert a cookie within the HTTP header to ensure that users continue to be directed to the specific PeopleSoft web server host where the session state information resides.


  • Performance

    FortiGate is a key component in this architecture and the selection of the FortiGate model, Compute shape, and launch options impact the performance of the workload. Verify the list of models with their respective specificatioins in the FortiGate data sheet.

  • Security

    FortiGate uses either OCI IAM Dynamic groups or API Signing keys for making the API calls in the event of failover. Set up policies based on your security/compliance requirements.

  • Availability

    To ensure higher availability whenever there’s multiple Availability Domains in the region, deploy each host of your cluster on a different AD. Otherwise, select different Fault Domains to increase availability based on your anti-affinity rules. This rule is valid for both Fortinet and Oracle products.

  • Cost

    Fortinet, FortiGate, and FortiADC are available in the Oracle Cloud Infrastructure Marketplace.

    Fortinet FortiGate is available as a BYOL or Paid offering.

    Fortinet FortiADC is available only as BYOL.


To deploy PeopleSoft in the cloud using Fortinet Security Fabric, perform the following steps:
  1. Set up the required networking infrastructure as shown in the architecture diagram. See Set up a hub-and-spoke network topology.
  2. Deploy PeopleSoft on your environment.
  3. Choose from the following stacks in Oracle Cloud Marketplace. For each stack you choose, click Get App and follow the on-screen prompts: