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.
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.
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.
The following graphic depicts the architecture for this use case:
Figure 1: Use case network topology
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.
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.
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.
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
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.
Figure 3: Security policies on Palo Alto Networks VM
Ensure that you have the correct routes for spoke VCNs and default routes. You can follow this diagram as a reference.
Figure 4: Static routes on Palo Alto Networks VM
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.
In the OCI Console, following these steps for configuration:
Navigate to Networking, Load Balancers, and click Create Load Balancer.
Select Network Load Balancer.
Enter the name.
Select Private as visibility.
Select the correct VCN and subnet where you want to host your network load balancer.
Enter a listener name and select the listener type and port if any. Our example uses TCP Port 80.
Click Add Backend and select your backend interfaces and associated ports. Use the firewall untrust interface IP from the previous section.
Select Backend Health Check (HTTP/HTTPS/TCP/UDP).
Figure 5: Creating the network load balancer
Figure 6: Creating the network load balancer listener
Figure 7: Add backends to the load balancer
Figure 8: Add backend health check policy to your load balancer
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.
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.
[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 ~]$
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).
Figure 9: Traffic flow on Palo Alto Networks VM
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: