- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
on 07-10-2023 10:06 AM
This document describes the use-cases, architecture design and traffic flows for Palo Alto Networks VM-Series deployed in Active-Passive mode in Google Cloud. The Active-Passive architecture provides several advantages over the Active-Active architecture like stateful failover, eliminates several source NAT requirements, and can be used for static IPSec termination. This document is intended for network administrators, solution architects, and security professionals who are familiar with Compute Engine, Load Balancing and Virtual Private Cloud (VPC) networking.
The VM-Series NGFW helps enterprises secure their applications, users, and other data deployed across Google Cloud and other virtualization environments.
Palo Alto Networks delivers zero-trust security capabilities for all enterprise networks by using the following approaches to threat prevention:
The VM-Series NGFW helps secure workloads deployed across both your VPC networks and your remote networks. Consider the following ways that the VM-Series NFGW can help to secure network patterns. The items in the following list correspond to the numbers in the following diagram.
For more information, see VM-Series Virtual Next-Generation Firewalls.
The architecture is very similar to the traditional Load Balancer (LB) architecture recommended for GCP in which the external LB points manages the untrust traffic and an internal LB manages the trust/egress or east-west traffic.
In the above architecture diagram, the VM-Series firewalls are deployed in an Active-Passive pair. Each firewall belongs to an Unmanaged Instance Group that is deployed to separate zones within the same region. Each firewall has four interfaces: MGMT/HA1, untrust, trust, and HA2, and each interface is connected to a dedicated VPC network.
The following sections explain the network components in more detail.
Each firewall is associated with an Unmanaged Instance Group, deployed across different zones to ensure redundancy and fault tolerance. The Instance Group allows the VM-Series to function as the backend service for Google Cloud's network load balancers. In the load balancer configuration, each instance group is designated as an active backend service. However, the health check performed by the load balancer towards the passive firewall will fail since its dataplane is inactive.
The Backend Service contains a crucial piece of configuration that would enable session stickiness on failover. The “Connection Tracking Policy” on the Backend Service configuration should have the following values:
It must also be noted that the Session Affinity on the Backend Service configuration should be set as “None” for best results.
The external TCP/UDP load balancer forwards inbound traffic from the internet to the untrust interface of the active VM-Series firewall. It also serves as the internet gateway for egress traffic from Google Cloud resources protected by the VM-Series. For the VM-Series to receive traffic from any external load balancer, a management interface swap must be performed. The swap enables the untrust interface to serve as the primary interface of the compute instance.
The internal TCP/UDP load balancer forwards outbound traffic from Google Cloud resources to the trust interface of the active VM-Series firewall. Custom routes are defined in the workload networks to use the internal TCP/UDP load balancer’s forwarding rule as the next hop.
In addition to the three VPC Networks that are required for Management, Untrust and Trust traffic arriving at the VM-Series firewalls, we need another VPC Network, HA2, that will be specifically used for session synchronization between the active and passive firewalls. The configuration synchronization will be performed using the Management network.
The VM-Series firewalls are configured as an Active-Passive pair. Configuration changes are automatically synced across the firewalls. It is crucial that the firewalls have identical licenses and are running the same PAN-OS version. This ensures consistency and compatibility between the firewalls, enabling seamless failover and synchronization of configurations and policies.
The diagram below illustrates how incoming traffic flows are processed with the Active-Passive architecture. The External Load Balancer, being a pass-through service, passes the flows onto the Active VM-Series firewall. The VM-Series firewall performs Destination NAT on the traffic to forward the flows to the intended destination after processing. Because the workload network has a default route returning the internal load balancer, source NAT is not required.
The diagram below illustrates how outgoing traffic flows are processed with this architecture. All traffic flows originating from the internal networks are forwarded to the Internal Load Balancer through custom routes. The VM-Series applies a source NAT to translate the traffic to the external load balancer’s forwarding rule.
The Active-Passive architecture design for VM-Series Next-Generation Firewalls provides solutions for some of the requirements that cannot be achieved through the Active-Active design with Autoscaling like;
With this design, we can achieve Session Synchronization and Stateful failover in case the Active Firewall goes down. Furthermore, the stateful failover can be achieved as quickly as 3 seconds.
By using the public IP address of the External Load Balancer as the VPN Gateway, we can now terminate the IPSec tunnels directly on the VM-Series firewalls, thereby achieving highly available and resilient VPN connections.
Some legacy applications may need visibility into the original source client IP address. With this design, there is no inherent need to apply Source Network Address Translation on the incoming traffic flows as traffic symmetry is always maintained.
The VM-Series firewall supports the following license types:
It also supports the following two licensing models:
Both models license security services and other features.
For more information on licensing, see VM-Series Firewall Licensing.
The VM-Series uses the following billable components of Google Cloud:
For more information, see License the VM-Series Firewall. To generate a cost estimate based on your projected usage, use the pricing calculator. New Google Cloud users might be eligible for a free trial.
Palo Alto Networks Single-Pass Architecture processes the following items only once:
This check significantly reduces the processing overhead required to perform multiple functions on a single device. For more information, see VM-Series on Google Cloud Performance and Capacity.
Hi community,
Regarding IPSec termination of Site-to-Site VPN Tunnels
"By using the public IP address of the External Load Balancer as the VPN Gateway"
You mean VPN Gateway at the Palo Alto site when you create the IPSec Tunnels pointing to the GCP External LB public IP?
Not the VPN Gateway concept for the Cloud VPN google cloud managed service.
Right?
Thanks in advanced
Hello Fran,
Thank you for your comment.
Yes, assuming you have IPSec tunnels originating from any source, including other Palo Alto NGFWs, the remote IP address for tunnel termination will be the public IP address of External LB on this active-passive architecture.
Thank you!
Thanks for your reply @shv .
We already have implemented this Palo Alto HA reference architecture. Let me kindly share our issues with the following Palo Alto configuration:
- 2x virtual router:
vr-trust:
- ethernet 1/2
- Loopback.1: 100.64.0.1/32
- Static Routes for GCP probes for Internal LB to ethernet 1/2
- Static default 0.0.0.0/0 to next vr-untrust
- NAT policy from GCP probes to ethernet 1/2 and DNAT loopback.1
vr-untrust:
-ethernet 1/1
-Loopback.3: 100.64.0.2/32
-Loopback.2: IP External LB GCP
-Static Routes for GCP probes for External LB to ethernet 1/1
- Static default 0.0.0.0/0 to ethernet 1/1
-NAT policy from GCP probes to ethernet 1/1 and DNAT loopback.3
With this design We have incoming traffic flowing to the spokes in GCP through the External LB and Health check traffic from Google probe successfully running. NAT rules for inbound and health checks are OK
For Outgoing traffic If We configure loopback 2 for the source NAT policy to translate the traffic to the external load balancer’s forwarding rule the NAT policy for health-check prob untrust with the loopback.3 fails and all the ingress traffic and health checks fails. Traffic from the health probes to the External LB trying to DNAT using loopback.2 instead of loopback.3.
Do you know How can we solve this issue?
And the last one related to IPSec termination from any source to the external LB We understand that passthrough Network Load Balancers are not proxies. Load-balanced packets are received by backend VMs with the packet's source and destination IP addresses, protocol, and, if the protocol is port-based, the source and destination ports unchanged. Load-balanced connections are terminated at the backends. Responses from the backend VMs go directly to the clients, not back through the load balancer. So the traffic flow from the source peer VPN Gateway to the External LB and the response is directly from the untrust Interface, not the external LB IP. Do we need to NAT outgoing traffic from untrust zone to untrust zone to the loopback.2 as well? Source vpn Gateway are waiting to recevie traffic from the Public IP of the External LB.
Thanks in advanced! We appreciated your support on these issues.