How to use a flexible network load balancer with a Palo Alto Networks virtual firewall appliance

April 8, 2021 | 6 minute read
Arun Poonia
Principal Solutions Architect
Text Size 100%:

Oracle Cloud Infrastructure (OCI)’s flexible network load balancer allows end users to support traffic load balancing using TCP/UDP/ANY ports to your intended destinations. This blog teaches you how you can use the flexible network load balancer to steer your ingress traffic from on-premises networks to Palo Alto Networks VM Series Firewalls and connect to your Web Spoke VM.

Check out the official flexible network load balancer announcement in this blog.

Use Case

This use case is validated by the blog author and Ajay Chhabria collaboratively.

Flexible network load balancer gives us the flexibility of using Layer-4 load balancing (TCP/UDP/ANY). In this use case, we want to achieve connectivity of on-premises networks to a Web Spoke VM running on OCI through a flexible network load balancer and a virtual firewall. Our use case uses the network load balancer in transparent mode to maintain the source IP associated with traffic. You can scale your architecture by adding more virtual firewall appliances as needed.

We use only one firewall VM, but in a production environment, use multiple firewall VMs to support the network load balancer sandwich approach.

Prerequisites

  • An Oracle Cloud account. If you don’t have an account, you can sign up for an Oracle Cloud Free Tier account.

  • A working hub and spoke network topology

  • A working firewall VM present in the hub VCN

  • A working application load balancer-as-a-service to steer traffic to web application VMs listening on HTTP. Web application VMs run Apache service on Port 80.

  • A working on-premises connection to your hub VCN. Refer to supported on-premises options.

Topology

The following graphic depicts the architecture for this use case:

A graphic depicting the architecture for this use case.Figure 1: Use case network topology

Configuration

Follow this section to add the required minimum configuration on Firewall VM and OCI to integrate with the network load balancer. For more configurations, follow this reference architecture.

Palo Alto Networks Firewall VM

In your hub and spoke topology, you need the Palo Alto Networks bring-your-own-license or paid VM listing from OCI Marketplace. After you’ve configured required interfaces, zones, address groups, and routes, complete the following steps to support the traffic:

  • Create a health probe to support HTTP health check on untrusted interface.

  • Open the required security policies to support traffic.

  • Add the correct routes pointing to your spoke VCNs and default gateway.

Create a health probe on untrust interface

Connect your firewall VM UI. To create your health probe on the untrusted interface to support HTTP/HTTPS health checks, click Untrust Interface, Advances, and select Management Profile.

A screenshot of the Interface Management Profile window in the PA-VM console.
Figure 2: Create a health probe on Palo Alto Networks VM

Now your untrusted interface IP responds to a health check from your network load balancer on [untrust_interface_ip]/php/login.php

Security policies

Enable security policies at a minimum to support ingress traffic. You can allow all for test purposes, but ensure that you enable only the required policies on Firewall VMs in your production environment.

A screenshot of active security policies in PA-VM.
Figure 3: Security policies on Palo Alto Networks VM

Default routes

Ensure that you have the correct routes for spoke VCNs and default routes. You can follow this diagram as a reference.

A screenshot of the default virtual router in PA-VM.
Figure 4: Static routes on Palo Alto Networks VM

Oracle Cloud Infrastructure

With a working OCI setup, you need to create a network load balancer and update route tables associated with subnets and your dynamic routing gateway to support ingress traffic.

Network load balancer

In the OCI Console, following these steps for configuration:

  1. Navigate to Networking, Load Balancers, and click Create Load Balancer.

  2. Select Network Load Balancer.

  3. Enter the name.

  4. Select Private as visibility.

  5. Select the correct VCN and subnet where you want to host your network load balancer.

  6. Enter a listener name and select the listener type and port if any. Our example uses TCP Port 80.

  7. Click Add Backend and select your backend interfaces and associated ports. Use the firewall untrust interface IP from the previous section.

  8. Select Backend Health Check (HTTP/HTTPS/TCP/UDP).

A screenshot of the Create Load Balancer page in the Console.
Figure 5: Creating the network load balancer

A screenshot of the Create Load Balancer page on the Configure Listener tab.
Figure 6: Creating the network load balancer listener

A screenshot of the Add Compute Instance Backends window in the load balancer creation section.
Figure 7: Add backends to the load balancer

A screenshot of the Specify Health Check Policy page in the load balancer creation section of the Console.
Figure 8: Add backend health check policy to your load balancer

Route Tables

Update your route tables to reflect the correct routes for your topology:

  • DRG route table: Use Spoke VCN CIDR as the destination with target of Network Load Balancer VIP IP.

  • Firewall untrusted subnet: If you plan to have outbound connectivity, create an entry for Default route as destination with the target set to internet gateway.

    Create an entry for on-premises or outbound CIDR as the destination with a target of DRG. This placeholder gives you a future smooth transition to support NAT natively on your flexible network load balancer.

  • Firewall trusted subnet: Create entries for each spoke VCN CIDR as your destination with the target of Hub LPGs.

  • Local peering gateway IPs: Create entries for each hub LPG as the destination with a target of your Firewall VM trusted interface IP address.

Validation

Now, you can validate the traffic from the client VM and inspect the traffic from Palo Alto Networks VM Series firewall.

To initiate traffic from the client VM, use the following specifications:

  • Client VM source IP address: 172.16.1.69

  • Destination application load balancer IP address: 10.0.0.132

The destination IP belongs to the application load balancer, which has web application VMs as the backend. In this case, you’re trying to reach to the application load balancer using port 80, which is exposed as listener port.

Copied to Clipboard
Error: Could not Copy
Copied to Clipboard
Error: Could not Copy
[opc@client ~]$ ip addr
1: lo: <loopback,up,lower_up> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens3: <broadcast,multicast,up,lower_up> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:00:17:09:37:b6 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.69/24 brd 172.16.1.255 scope global dynamic ens3
       valid_lft 60980sec preferred_lft 60980sec
[opc@client ~]$
[opc@client ~]$ curl http://10.0.0.132
<h1>This is a Test Page Serving from Spoke VCN Web Application VM 1</h1>
[opc@client ~]$</broadcast,multicast,up,lower_up></loopback,up,lower_up>

You can inspect the traffic flow from Palo Alto Networks Firewall VM. The traffic comes from the client VM IP, 172.16.1.69. The traffic goes to the application load balancer IP address, 10.0.0.132, using the destination port HTTP(80).

A screenshot of the traffic flow on the Palo Alto Networks VM.
Figure 9: Traffic flow on Palo Alto Networks VM

Conclusion

This post explained how to use a network load balancer to support on-premises network traffic through a Palo Alto Networks VM Series firewall in a hub-and-spoke topology. You can use this post as a reference to validate different firewall appliances and enhance your use cases.

For more information on how to use load balancers, hub and spoke architecture, and more, see the following references:

Arun Poonia

Principal Solutions Architect

Arun Poonia is a Principal Solutions Architect whose work is currently focused on Oracle Cloud Infrastructure. His experience at Oracle has been around Strategic Partnership, OCI/Azure Interconnect, Security & Developer Services and OCI Marketplace; Networking & Security.

 

Prior to joining Oracle, Arun was a Solutions Architect working primarily on various Networking & Security products; associated customers and partners. His experience over the last 11 years was around architecting, planning, implementation and integration of Networking & Security solution with large enterprise customers and supporting them on hybrid cloud solutions.

Show more

Previous Post

Deploying Oracle Cloud and Microsoft Azure Interconnect using Terraform

Arun Poonia | 4 min read

Next Post


ServiceNow and Oracle Cloud Infrastructure integration for ITOM visibility and AIOps

Zeke Kaufman | 3 min read
Oracle Chatbot
Disconnected