>
    Strata Copilot
    Securing VPC Networks with VM-Series Firewall on GCP
    Focus
    Download PDF
    Focus
    1. Home
    2. VM-Series
    3. VM-Series Firewall on Google Cloud Platform
    4. Securing VPC Networks with VM-Series Firewall on GCP
    Download PDF
    VM-Series

    Securing VPC Networks with VM-Series Firewall on GCP

    Table of Contents

    Securing VPC Networks with VM-Series Firewall on GCP

    Use the autoscale and active/passive deploymentconfigure-vm-monitoringconfigure-vm-monitoringonfigure-vm-monitoring modelsto secure Google Cloud networks.
    Where Can I Use This?What Do I Need?
    • Google Cloud Platform (GCP)
    • VM-Series License (PAYG or BYOL)
    • VM-Series plugin
    • Panorama
    • Panorama plugin for GCP
    There are several architectures the VM-Series supports to secure Google Cloud networks. Both the autoscale and active/passive deploymentconfigure-vm-monitoringconfigure-vm-monitoringonfigure-vm-monitoring models support the architectures described in this section.
    Multiple VPC networks can be secured using the multiple network interface architecture, VPC peering architecture, or a combination of both architectures.
    The following are architectures for deploying VM-Series firewalls in your Google Cloud Platform:

    Multiple Network Interface Architecture

    In the multiple interface architecture, additional dataplane interfaces are attached to workload VPC networks, with each interface set as a backend service of an internal pass-through load balancer. In the autoscale model, these load balancers distribute traffic to the firewalls. In the active/passive model, they manage stateful traffic failover between the firewall HA pair. Custom or policy-based routes in each workload VPC direct traffic to the respective load balancer within the same VPC.
    • In Google Cloud, a maximum of 8 interfaces can be allocated on a per virtual machine basis.
    • In Google Cloud, you cannot attach or detach network interfaces after a virtual machine is created. Therefore, it is important to plan your network interface allocation prior to firewall deployment.
    The following diagram is an example of the multiple interface architecture:
    The following examples show the different traffic patterns that run through the VM-Series firewalls in this configuration:
    1. An inbound request is made to an application hosted in VPC C. The external load balancer (External LB) distributes the request to the VM-Series untrust interfaces. The VM-Series firewall inspects and forwards the request through the NIC4 in VPC C and to the destination application.
    2. The route table of VPC B routes traffic that is destined to the internet to the IP address of Internal LB B (10.2.0.10). The load balancer distributes the traffic to NIC3 on the VM-Series firewalls. The VM-Series inspects and forwards the traffic through its untrust interface (NIC0) to the internet.
    3. A resource in VPC A makes a request to a resource in VPC B. The route table of VPC A routes the request to the Internal LB A . The load balancer distributes the request to NIC2 on the VM-Series. The VM-Series inspects and forwards the request through NIC3 to the resource in VPC B. VPC B routes its return traffic to Internal LB B using the route table of VPC B. .
    4. A resource in VPC A makes a request within VPC A. A policy based route within VPC A steers the intra-VPC traffic to the forwarding rule of Internal LB A. The VM-Series inspects and forwards the traffic through NIC2 to the destination in VPC A. The return traffic uses the same routing path as the request traffic.

    VPC Network Peering Model

    VPC Network Peering enables you to create a hub and spoke topology to secure many VPC networks with VM-Series. Unlike the multiple interface architecture, VPC peering enables you to connect and disconnect up to 25 workload VPCs as needed. In this architecture, the trust VPC serves as a hub network for workload VPCs which are connected as spoke networks. Each spoke VPC network has custom or policy-based routes to steer inter-VPC and intra-VPC traffic to the internal load balancer in the hub network.
    In the configuration displayed in the previous diagram, the VM-Series firewalls inspect the traffic as follows:
    1. Traffic from the internet to applications in the spoke networks is distributed by the external passthrough load balancer to the VM-Series untrust interfaces (NIC0). The VM-Series firewall inspects the traffic and forwards permissible traffic through its trust interface (NIC2) to the application in the spoke network.
    2. Traffic from the spoke networks destined to the internet are routed to the internal load balancer in the hub VPC. The VM-Series firewall inspects the traffic and forwards permissible traffic through its untrust interface (NIC0) to the internet.
    3. Traffic between spoke networks or traffic within a spoke network (routed via policy-based route) is routed to the internal load balancer in the hub VPC. The VM-Series firewall inspects and forwards the traffic through the trust interface (NIC2) into the hub network which routes permissible traffic to the destination spoke network.

    Combining the Architectures

    If you require transitive routing and security for more than 25 VPC networks, you can combine the multiple network interface and VPC peering architectures together. In this architecture, each additional dataplane interface serves as a hub network which can have up to 25 spoke VPC networks. Full transitive routing across the spoke networks and hubs is supported.

    Network Connectivity Center

    Network Connectivity Center (NCC) utilizes a hub-and-spoke model for managing global connectivity across diverse networks. By integrating VM-Series with NCC, a full mesh networking model is created between VM-Series and connected spokes. VM-Series connects to the hub as a router appliance, exchanging routes with Cloud Routers via BGP. This integration enables VPC-to-VPC connectivity across projects and organizations, secure remote network connections to Google Cloud, global WAN network creation, and cross-region failover. Two key topologies include VPC-to-VPC, facilitating route exchange between separate VPCs, and Global VPC, enabling regional failover and dynamic route propagation for continuous service across multiple regions.
    Network Connectivity Center (NCC) leverages a hub-and-spoke model to provide a 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. Integrating Google Cloud Network Connectivity Center with VM-Series 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, enabling you to exchange routes with Cloud Routers using BGPUsing the VM-Series firewall with NCC, enables you to achieve the following:
    • Connect multiple VPC networks to one another across projects and organizations within GCP. See VPC-to-VPC topologies for more information.
    • Connect remote networks to Google Cloud while providing full BGP route exchange. See site-to-cloud connectivity for more information.
    • Create a global WAN network secured with VM-Series deployed in Google Cloud. See site-to-site connectivity for more information.
    • Facilitate cross-region failover across regionally distributed firewalls.
    Topology 1: VPC-to-VPC Topology
    In this topology, two VM-Series firewalls are deployed, each with a network interface (NIC) in separate VPC networks (VPC 1 and VPC 2). Each NIC is configured as a router appliance spoke connected to an NCC hub and has established BGP peering with a cloud router in each VPC. In this scenario, the VM-Series firewalls and the Cloud Routers facilitate a full route exchange between VPC 1 and VPC 2. As a result, the workloads in VPC 1 have routes to reach the workloads in VPC 2 through the propagated routes. In the event of a zone or firewall failure, BGP route convergence propagates routes to the secondary VM-Series firewall, ensuring continuity.
    Topology 2: Global VPC
    Three VPCs have been created — mgmt, untrust, and vpc1 — with each containing subnets in the regions us-east1 and us-west1. Additionally, one VM-Series firewall has been deployed in each region (named us-east1-vmseries and us-west1-vmseries), with a network interface card (NIC) in each VPC. Specifically, the firewall's NIC in vpc1 is configured as a router appliance connected to an NCC hub. Within each region, the firewalls are configured as BGP neighbors with Cloud Routers, facilitating end-to-end route propagation. Should there be a regional failure, egress traffic from the affected region in vpc1 is automatically rerouted to the firewall in the remaining healthy region through dynamic route propagation, ensuring continuity of service.For more information, see Google Cloud NCC & VM-Series Tutorial.

    © 2026 Palo Alto Networks, Inc. All rights reserved.