Keeping Your Google Cloud VPC Networks Highly Resilient and Secured

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.
Community Team Member
100% helpful (1/1)

Graphics Created (25).jpg


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.


About VM-Series Next-Generation Firewalls


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:


  • Securing all applications with Layer-7 inspection, granting access based on user identification, and preventing known and unknown threats.
  • Segmenting mission-critical applications and data using zero-trust principles to improve security posture and achieve compliance with various security standards—for example, PCI DSS.
  • Using Panorama to centrally manage both physical and virtual firewalls. Panorama helps provide a consistent security posture across all hybrid and multi-cloud environments.
  • Using tooling to automate the deployment and configuration of VM-Series NGFWs.
  • Using predefined and custom network tags within security policies to dynamically update objects as Cloud workloads are created, moved, and destroyed.


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.


  1. Prevent inbound threats from the internet to resources deployed in VPC networks, on-premises, and in other cloud environments.
  2. Stop outbound connections from VPC networks to suspicious destinations, such as command-and-control servers, or malicious code repositories.
  3. Prevent threats from moving laterally between workload VPC networks and stealing data.
  4. Secure traffic between remote networks connected through Cloud Interconnect, Network Connectivity Center, or Cloud VPN.
  5. Help extend security to remote users and mobile devices to provide granular application access to Google Cloud resources.




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.


Unmanaged Instance Groups

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.


Backend Service

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:


  1. Tracking Mode – Per Session
  2. Connection Persistence on Unhealthy Backends – Never Persist
  3. Idle Timeout Seconds – 600 seconds


It must also be noted that the Session Affinity on the Backend Service configuration should be set as “None” for best results.


External Load Balancer

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.


Internal Load Balancer

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.


HA2 Network

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.


VM-Series Configuration

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.  


Traffic Flows


Incoming traffic flows

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.




Outgoing traffic flows

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. 




Use Cases


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;


Session synchronization and Stateful failover

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.


IPSec termination of Site-to-Site VPN Tunnels

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.


No SNAT Solution

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:


  • BYOL
  • PayGo


It also supports the following two licensing models:


  • Software Next Generation firewall credits: Flexible configurations that you specify with a deployment profile
  • Fixed VM-Series Model configurations


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:


  • Network policy enforcement
  • Application identification
  • User controls
  • Content inspection


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.


What’s Next?



Rate this article:
L0 Member

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.



Thanks in advanced

L1 Bithead

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!

L0 Member

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:


     - ethernet 1/2

     - Loopback.1:

     - Static Routes for GCP probes for Internal LB to ethernet 1/2

     - Static default to next vr-untrust

     - NAT policy from GCP probes to ethernet 1/2 and DNAT loopback.1


     -ethernet 1/1


     -Loopback.2: IP External LB GCP

     -Static Routes for GCP probes for External LB to ethernet 1/1

     - Static default 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.

Register or Sign-in
Article Dashboard
Version history
Last Updated:
‎07-10-2023 10:06 AM
Updated by: