- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
on 05-25-2021 06:16 AM - edited on 11-09-2022 12:02 PM by mmclimans
Palo Alto Networks VM-Series Next-Generation Firewall for Google Cloud is the industry-leading virtualized firewall to protect applications and data with next-generation security features that deliver superior visibility, precise control, and threat prevention at the application level. The VM-Series capabilities to secure globally connected networks are further enhanced by its integration with Network Connectivity Center by Google Cloud.
There are several components used to integrate the VM-Series with Network Connectivity Center.
Network Connectivity Center – Hubs and Spokes
Network Connectivity Center leverages a hub-and-spoke model to provide end-users a single place to manage global connectivity across various networks. The hub is a global resource that connects attached spokes with a simple and singular connectivity model. The Network Connectivity Center hub creates a full mesh networking model between the VM-Series and all other connected spokes. The VM-Series connects to the hub as a router appliance spoke.
Google Cloud Router
The VM-Series integrates with Network Connectivity Center by establishing BGP peering relationships with a VPC’s Cloud Router. This relationship enables full route propagation between remote networks and the Google Cloud VPC fabric routes.
Once the peering relationship is established between the Cloud Router and the VM-Series, routes from remote networks, Google Cloud VPCs, and the VM-Series are exchanged. If the VM-Series firewalls are deployed within the same spoke, the hub advertises the same prefixes to all of the firewalls. This behavior enables equal-cost multipath (ECMP) for hub to firewall traffic. If you prefer to isolate traffic flows to dedicated firewalls, the VM-Series should be placed in separate spokes with different ASNs.
The VM-Series can be used to secure traffic from remote networks to Google Cloud VPCs. The following outcomes are achieved through the integration with Network Connectivity Center:
In this topology, VM-Series firewalls are deployed across different zones within the same region. The firewalls are connected as a single spoke to the Network Connectivity Center hub and have a BGP session established with the VPC’s Cloud Router. From on-premises, IPsec tunnels are created and terminated on each firewall. Routes to and from the remote network and the VPC are exchanged through the VM-Series and Cloud Router. The VM-Series firewalls are advertising the same prefixes and MED values to take advantage of Google Cloud’s ECMP functionality. The use of ECMP provides redundancy and load distribution among the zonally distributed firewalls.
The architecture shows two VM-Series pairs (within the same VPC) distributed across two Google Cloud regions. Each firewall pair is a separate spoke connected to the Network Connectivity Center hub. The Cloud Router BGP peers with its respective regional firewall pair. Routes from the remote sites are advertised to the VM-Series firewalls via the Cloud Router. The Cloud Routers themselves exchange routes to provide full mesh connectivity.
Nice addition gives a lot of flexibility in GCP,
I have a customer who I have helped deploying firewalls behind GCP iLB (internal LB) and set the next hop to the iLB. They are using Interconnect (Dedicated) no the IPsec tunnel for accessing on-prem.
Would you consider another topology where iLB as the next-hop is used as an extension of 1a and 2a as a supported method?
Unfortunately I wasn't able (anymore?) to edit the above comment.
However I managed to setup the BGP peering, but GCP won't redistribute imported VPC peering routes automatically.
Is this something that can be changed, without the need to add them as custom routes to the redistribute profile of the cloud router ?
In this solution, can the Palos be ran as a HA cluster and they share session info?
E.g.
Outbound Traffic: Onprem-server1 -> Palo1 -> Cloud-Server1
Reply traffic: Cloud-server1 -> Palo2 -> Onprem-server1
Thanks,
Aidan.