1. Deploy Palo Alto firewall in Active/Active mode with OCI Flexible Network Load Balancer
  2. Learn About Deploying Palo Alto firewall in Active/Active mode with OCI Flexible Network Load Balancer

Learn About Deploying Palo Alto firewall in Active/Active mode with OCI Flexible Network Load Balancer

This document provides a guide for deploying Palo Alto VM-Series firewalls in Active/Active mode within Oracle Cloud Infrastructure (OCI).

Although Palo Alto natively supports Active/Active High Availability (HA) functionality in on-premises data centers, this is not feasible in public cloud environments. However, a workaround for this deployment has been made possible in OCI, using a breakthrough feature called symmetric hashing in the OCI Flexible Network Load Balancer.

In this deployment model, the Palo Alto firewall functions as a passthrough device, meaning it does not require network address translation (NAT) or public IP addresses. The public IP address is instead associated with the actual DMZ server or load balancers. As a result, there is no need for additional NICs, even when the maximum number of secondary IPs is reached. This functionality is enabled by the option to attach route tables to the NAT gateway, internet gateway, and service gateways in OCI.

Advantages:

  1. Increased throughput: Both firewalls are active, resulting in higher throughput.
  2. Seamless scaling: New firewalls can be deployed without disrupting existing traffic, and they can be added to the backend of the Network Load Balancers.
  3. Reduced failover time: Failover is faster as there is no need for API calls to move the IP address from the primary to the secondary device.
  4. No OCI Identity and Access Management policy configuration: OCI Identity and Access Management policy configuration is not required to allow the Palo Alto firewall to read VCN and manage the movement of NICs.
  5. No additional NICs required: When the number of public IPs exceeds 64, there is no need for additional NICs, as no public IPs are associated with the firewall. The size of the DMZ subnet determines the maximum number of services or applications that can be exposed to the internet.
  6. Cost savings: Licensing and VM operation costs are reduced since this model does not require additional NICs.

Before You Begin

To understand this deployment model better, see the following links that talk about the symmetric hashing functionality of OCI Flexible Network Load Balancer and Palo Alto deployment in OCI.

Architecture

The following diagram shows the high-level architecture used for testing the Palo Alto Active/Active setup in OCI.

This is a typical hub spoke architecture deployment in OCI, where the Active/Active Palo Alto firewall is deployed with four NICs on Hub VCN, added to that we will have a public subnet for DMZ in the Hub VCN. The Spoke VCNs will be attached to the DRG in order to route all the North-South, East-west via the Palo Alto firewalls. Active/Active setup is achieved by adding the Palo Alto VMs as backend of Inbound and Trust NLBs.

In this section we will dive deep into the traffic routing and flows in this reference architecture. The term "tok" in the names of the resources refer to the region Tokyo where this reference architecture model was deployed and tested.


Description of oci-nlb-palo-alto-active-active-arch.png follows
Description of the illustration oci-nlb-palo-alto-active-active-arch.png

oci-nlb-palo-alto-active-active-arch-oracle.zip

North-South Inbound Internet traffic flow to OCI:

The following diagram depicts the flow of DMZ web service exposed to the internet. The application load balancer is on a public subnet and the backend servers are in private subnets of Spoke VCN. The detailed flow on each hop is described in the following steps.


Description of oci-nlb-palo-alto-active-active-dmz.png follows
Description of the illustration oci-nlb-palo-alto-active-active-dmz.png

oci-nlb-palo-alto-active-active-dmz-oracle.zip

  1. Traffic from the client machine on the internet is routed to the Internet gateway (IGW).
  2. IGW will refer to the internet gateway route table to the subnet “hub-tok-publiclb-sn” and route the traffic to the Inbound NLB IP 10.1.1.198.
  3. Inbound NLB will load balance the traffic to the one of the PA devices in the backend using the symmetric hashing algorithm.
  4. Firewall will validate the policy, route the traffic out of its inbound interface on virtual router “inbound-rtr” to the application load balancer that has the public IP.

    Note:

    The firewall security policy will be written to the Private IP (10.1.1.112) of the public load balancer.
  5. OCI Flexible Network Load Balancer will perform the Source Network Address Translation (SNAT) for the traffic and route it to the dynamic routing gateway (DRG) referring to the subnet route table.
  6. DRG referring to the route table of the Hub VCN attachment, routes the traffic to the Spoke VCN and traffic reaches the web server.
  7. Web server will send the return traffic to the DRG attachment according to the subnet route table.
  8. DRG will refer to the route table of the Spoke VCN attachment and send the traffic to the OCI Flexible Network Load Balancer in the hub.
  9. OCI Flexible Network Load Balancer will UNAT the traffic and use the default route of the subnet to send the traffic to the Inbound NLB IP 10.1.1.198.
  10. Inbound NLB will forward the traffic to the same PA device in the backend that initiated the traffic using the symmetric hashing algorithm.
  11. Palo Alto receives the traffic on the Inbound NIC and per the default route of virtual routers sends the traffic back to the internet gateway.
  12. The internet gateway routes the traffic to the internet client.

North-South Outbound Internet traffic flow from OCI:

The following diagram depicts the flow of outbound internet traffic from OCI. All the VMs in OCI will use Palo Alto's SNAT and OCI NAT gateway to access the internet. Palo Alto’s SNAT is needed to make the return path symmetric. The outbound public IP address will be the IP address of the NAT gateway.


Description of oci-nlb-palo-alto-active-active-outbound.png follows
Description of the illustration oci-nlb-palo-alto-active-active-outbound.png

oci-nlb-palo-alto-active-active-outbound-oracle.zip

  1. Traffic from the VM in the Spoke subnet using the default route to DRG, routes the traffic to the DRG attachment.
  2. DRG refers to the attachment route table of the spoke and routes the traffic to the Hub VCN and transit Route table of VCN routes the traffic to the Trust NLB IP 10.1.1.229.
  3. NLB load balances the traffic to one of the Firewalls in Active/Active mode.
  4. Firewall receives the traffic on trust interface in default virtual router. It does SNAT for the traffic to the untrust interface IP and referring to default route forwards the traffic to the OCI NAT gateway.
  5. NAT gateway routes to the traffic to internet using the NAT gateway’s Public IP.
  6. Internet re-routes the return traffic to the NAT gateway.
  7. NAT gateway UNAT's the traffic and routes it back to the same Palo Alto interface as there was a SNAT on Palo Alto.
  8. Palo Alto based state table and routes on the default virtual router sends the traffic out of trust NIC to the DRG after the reverse NAT gateway.
  9. DRG refers to the route table attached to the Hub VCN and routes to the respective Spoke VCN and reaches the source VM.

East-west traffic between spokes in OCI or on-premises to OCI:

The following diagram depicts the flow of traffic between on-premises and OCI. To understand the flow of traffic between spokes in OCI, we can consider on-premises as one of the spokes. In that case the only change is the route table referred on the Spoke attachment. This deployment can be referred to single arm mode, where the traffic will enter and leave the same interface of the firewall, here the interface is the trust interface.


Description of oci-nlb-palo-alto-active-active-onprem.png follows
Description of the illustration oci-nlb-palo-alto-active-active-onprem.png

oci-nlb-palo-alto-active-active-onprem-oracle.zip

  1. On-premises traffic is routed to the OCI DRG either via IPSec or OCI FastConnect.
  2. DRG refers to the attachment route table of the OCI FastConnector IPSec and route the traffic to Hub VCN, The VCN attachment route table on the hub routes traffic to the Trust NLB IP 10.1.1.229.
  3. NLB load balances traffic to the one of the firewalls in Active/Active mode.
  4. Firewall processes traffic according to the security rule and routes back to DRG on the Hub route table in the Hub attachment.
  5. DRG refers to the route table attached to the Hub attachment and routes the traffic to respective Spoke VCN and the respective VM.
  6. The VM sends the return traffic to the DRG referring to the default route rule in the route table.
  7. DRG refers to the route table attached to the Spoke VCN and routes the traffic to Hub VCN, Hub transit route table routes the traffic to the Trust NLB.
  8. NLB load balances the traffic to the same Palo Alto device using the symmetric hashing algorithm.
  9. Firewall refers the state table and routes of default virtual router and send the traffic back to the DRG on the Hub route table in the Hub attachment.
  10. DRG refers to the Hub route table in the Hub attachment and routes the traffic to on-premises via the OCI FastConnect or IPSec tunnel.

East-west Outbound traffic flow from OCI VMs to Oracle Services Network:

The following diagram depicts the flow of outbound traffic from OCI VMs to the Oracle Services Network. All VMs in OCI will use Palo Alto’s SNAT and OCI gervice gateway to access the Oracle Services Network. Palo Alto’s SNAT is needed to make the return path symmetric. On the Oracle Services Network, if you need to whitelist the VCN, it will be the Hub VCN ranges.


Description of oci-nlb-palo-alto-active-active-osn.png follows
Description of the illustration oci-nlb-palo-alto-active-active-osn.png

oci-nlb-palo-alto-active-active-osn-oracle.zip

  1. Traffic from the VM in Spoke subnet using the default route to DRG, routes the traffic to the DRG attachment.
  2. DRG refers to the attachment route table of the spoke and routes the traffic to Hub VCN and VCN Attachment route table on Hub VCN routes the traffic to the Trust NLB IP 10.1.1.229.
  3. Trust NLB load balances the traffic to the one of the firewalls in Active/Active mode.
  4. Firewall receives the traffic on trust interface on the default virtual router. It does SNAT for the traffic to the untrust interface IP. Then referring to default route it forwards the traffic to OCI Subnet route table and then to the OCI service gateway.
  5. The service gateway routes the traffic to the Oracle Services Network via the OCI backbone and sends the return traffic back to the same interface of the firewall as there was a SNAT on Palo Alto.
  6. Palo Alto refers to the state table, performs the reverse NAT and based on the static route on default virtual router sends the traffic out of trust NIC and to the DRG eventually.
  7. DRG refers to the route table attached to the Hub VCN and routes the traffic to respective Spoke VCN and then to the source VM.

This architecture supports the following components:

  • Network Load Balancer

    Network Load Balancer is a load balancing service which operates at Layer-3 and Layer-4 of the Open Systems Interconnection (OSI) model. This service provides the benefits of high availability and offers high throughput while maintaining ultra-low latency.

  • Palo Alto firewall

    The VM-Series next-generation firewall protects your applications and data with the same security capabilities that protects the customers infrastructure in cloud. The VM-Series next-generation firewall allows developers and cloud security architects to embed inline threat and data loss prevention into their application development workflow.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

  • Internet gateway

    An internet gateway allows traffic between the public subnets in a VCN and the public internet.

  • Network address translation (NAT) gateway

    A NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.

  • On-premises network

    This is a local network used by your organization.

  • Route table

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

  • Service gateway

    The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.

  • Virtual cloud network (VCN) and subnet

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.