Modernizing Enterprise Cloud Security: Building an Autoscale Multi-NIC Palo Alto Stack on Google Cloud NCC Mesh Topology

Google Cloud Community Articles
,
1

Enterprise cloud security architectures have reached a critical inflection point. As cloud footprints grow across hundreds of workload projects, traditional hub-and-spoke routing models quickly succumb to “route fatigue,” complex symmetric hashing issues, and operational bottlenecks.

By combining Google Cloud Network Connectivity Center (NCC) Mesh Topology with GCP Network Security Intercept (NSI) and Palo Alto Networks VM-Series Multi-NIC Firewalls, enterprises can construct an enterprise-grade Zero Trust architecture.

This post details how to design an automated, highly available, and transparent security backbone that scales effortlessly from local application inspection to multi-region Disaster Recovery (DR).

The architectural challenge

Historically, inline security inspection in Google Cloud required complex static routing, custom route tables, and forced Source NAT (SNAT) to ensure symmetric traffic return.

When managing multiple business units, third-party integrations, and hybrid environments, traditional hub-and-spoke topologies create severe friction:

  1. Routing Sprawl: Managing dynamic BGP route exchanges or complex static routes across dozens of peered VPCs introduces human error and configuration drift.

  2. Loss of Visibility: Forcing SNAT on internal traffic obscures the real client IP address, hampering audit trails and incident response.

  3. Complex Internet Egress: Egress traffic frequently requires multiple extra network hops, driving up inter-VPC bandwidth costs and introducing latency.

To eliminate these constraints, we implement a Mesh Topology using NCC, combined with NSI In-Band Packet Interception and Palo Alto NSI Overlay Support.

1. Centralized Multi-NIC Palo Alto Interface Topology

Inside the dedicated Central Transit Project, Palo Alto VM-Series firewalls operate across three strictly isolated Virtual Private Cloud (VPC) networks. This multi-NIC setup provides complete physical air-gapping between management, internal data plane, and public egress paths.

                     ┌───────────────────────────────────────┐
                     │     Palo Alto VM-Series Appliance     │
                     └───────┬───────────┬───────────┬───────┘
                             │           │           │
            ┌────────────────┘           │           └────────────────┐
            ▼                            ▼                            ▼
┌───────────────────────┐   ┌─────────────────────────┐   ┌───────────────────────┐
│ nic0: Management VPC  │   │ nic1: Transit/Trust VPC │   │nic2: Egress/Untrust   │
│  (10.10.10.0/24)      │   │   (10.196.90.0/24)      │   │  (10.250.10.0/24)     │
└───────────┬───────────┘   └────────────┬────────────┘   └───────────┬───────────┘
            │                            │                            │
   Panorama Management            NCC Mesh Spoke              Central Cloud NAT
   (No NCC Attachment)        (GENEVE UDP Port 6081)             & Direct Exit

  • nic0 (Management VPC): Dedicated strictly to out-of-band administration, SSH/HTTPS access, software updates, and synchronization with Palo Alto Panorama. It is completely detached from the NCC Mesh topology to prevent administrative exposure.

  • nic1 (Transit / Trust VPC): Attached as a core spoke to the central NCC Mesh fabric. It receivesGENEVE-encapsulated payload traffic over UDP Port 6081 via an Internal Passthrough Network Load Balancer.

  • nic2 (Egress / Untrust VPC): Detached from the NCC Mesh fabric. Serves as the L3 exit interface for unencapsulated outbound internet traffic, routing through a central GCP Cloud NAT gateway.

2. Decoupling Security via NCC Mesh Topology

Instead of a rigid Star/Hub-and-Spoke structure, the Network Connectivity Center (NCC) Mesh Topology allows all participant VPC networks (Transit Hubs, Core Service Spokes, and Workload VPCs) to establish direct, full-mesh control plane route propagation over Google’s global SDN fabric.

                  ┌──────────────────────────────────────────────┐
                  │            NCC Mesh Control Plane            │
                  │             (Global Route Exchange)          │
                  └──────┬──────────────────────┬─────────┬──────┘
                         │                      │         │
                         ▼                      ▼         ▼
        ┌─────────────────────────┐   ┌────────────────────────┐   ┌────────────────────────┐
        │  Transit Security VPC   │   │ Core App Spoke A VPC   │   │ Core App Spoke B VPC   │
        │  (Palo Alto nic1 Hub)   │   │   (Workload Network)   │   │   (Workload Network)   │
        └─────────────────────────┘   └────────────────────────┘   └────────────────────────┘

By leveraging a Mesh topology:

  • Any-to-Any Reachability: Workload spokes receive optimized routing paths without requiring manual VPC peering meshes.

  • Non-Disruptive Onboarding: Onboarding a new tenant or application spoke simply requires attaching its VPC to the NCC Mesh.

  • Transparent Security Interception: Rather than relying on static default routes, traffic is redirected into the Palo Alto inspection cluster transparently at the hypervisor layer using GCP Network Security Intercept (NSI).

3. End-to-end traffic flows

Flow A: Inbound Internet Ingress (external user to workload)

  1. Public Ingress: An external user sends HTTPS traffic targeting the Anycast IP of a Global External Application Load Balancer.

  2. GFE Proxy: Google Front Ends (GFEs) terminate the SSL session at the global edge and proxy the HTTP/HTTPS request directly into the target Workload VPC subnet.

  3. Hypervisor Intercept (Andromeda): As the packet hits the destination Compute Engine instance’s virtual NIC (vNIC), a Global Network Firewall Policy with a Security Profile Group (SPG) triggers an NSI intercept.

  4. GENEVE Encapsulation: The hypervisor wraps the original IP packet inside a GENEVE header (UDP 6081) and forwards it across the network to the Internal Load Balancer in the Transit VPC.

  5. L7 Inspection: The Palo Alto terminates the GENEVE tunnel on tunnel.1, applies Threat Prevention/App-ID profiles, and returns the approved packet directly to the backend workload VM via Direct Server Return (DSR).

Code snippet

flowchart TD
    User["Public Internet User"] -->|"1. Anycast IP"| Ext_ALB["Global External Load Balancer"]
    
    subgraph Workload_VPC [Consumer Workload VPC]
        Ext_ALB -->|"2. Proxy to Subnet"| GFE_Proxy["GFE Proxy Ingress"]
        GFE_Proxy -->|"3. vNIC Hypervisor Intercept<br>(Global Firewall Policy SPG)"| Andromeda_SDN["Google SDN (Andromeda)"]
    end

    subgraph Transit_VPC [Central Transit Hub VPC]
        Andromeda_SDN -->|"4. GENEVE (UDP 6081)"| Int_LB["Internal Passthrough Load Balancer"]
        Int_LB -->|"Distributes Streams"| Trust_NIC["Palo Alto nic1 (Trust)"]
        
        subgraph PA_VM [Palo Alto VM-Series]
            Trust_NIC --> Tunnel["tunnel.1 Interface"]
            Tunnel --> L7_Engine["5. L7 Threat Scan & App-ID"]
        end
    end

    L7_Engine -->|"6. Direct Server Return (DSR)"| Workload_VM["Target Workload VM"]

    classDef ext fill:#fff3e0,stroke:#e65100,stroke-width:2px;
    classDef consumer fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef transit fill:#efebe9,stroke:#4e342e,stroke-width:2px;
    classDef firewall fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;

    class User,Ext_ALB ext;
    class GFE_Proxy,Andromeda_SDN,Workload_VM consumer;
    class Int_LB,Trust_NIC transit;
    class Tunnel,L7_Engine firewall;

Flow B: East-West Inspection (App Spoke A to App Spoke B)

  1. Initiation: A VM in App Spoke A sends an API request directly to a database VM in App Spoke B over the NCC Mesh topology.

  2. In-Band Hook: The egress firewall policy in Spoke A triggers an NSI hook prior to routing.

  3. GENEVE Preservation: Andromeda encapsulates the packet, preserving the original Source IP (10.196.12.50) and Destination IP (10.240.32.10) inside the GENEVE payload .

  4. Firewall Processing: The packet lands on tunnel.1 of the Palo Alto pool. The firewall evaluates the unencapsulated payload against Zone-Based policies.

  5. No SNAT Required: Because NSI uses Direct Server Return (DSR), the Palo Alto re-encapsulates the approved packet and sends it straight to App Spoke B. The destination database sees the true client source IP, preserving full visibility for application loggin g.

Flow C: Outbound Internet Egress (Palo Alto NSI Overlay)

For internet egress, the architecture leverages Palo Alto Networks’ GCP NSI Overlay Support:

Code snippet

flowchart LR
    subgraph Spoke_VPC [Workload Spoke VPC]
        VM["Workload VM<br>(10.196.12.50)"]
    end

    subgraph Transit_Project [Central Transit Security Project]
        ILB["Internal Load Balancer<br>(UDP 6081)"]
        
        subgraph PA_VM [Palo Alto VM-Series]
            nic1["nic1 (Trust)"]
            Tunnel["tunnel.1<br>(Decapsulation)"]
            Inner_Router["Inner Router & SNAT<br>(Source -> nic2 IP)"]
            nic2["nic2 (Untrust)"]
            
            nic1 --> Tunnel --> Inner_Router --> nic2
        end
        
        Cloud_NAT["Central Cloud NAT"]
    end

    VM -->|"1. NSI Intercept (GENEVE)"| ILB
    ILB --> nic1
    nic2 -->|"2. Unencapsulated IP"| Cloud_NAT
    Cloud_NAT -->|"3. Whitelisted Egress"| Internet(("Public Internet"))

    classDef spoke fill:#fff3e0,stroke:#e65100,stroke-width:2px;
    classDef transit fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef egress fill:#efebe9,stroke:#4e342e,stroke-width:2px;
    
    class Spoke_VPC,VM spoke;
    class Transit_Project,ILB,PA_VM,nic1,Tunnel,Inner_Router,nic2 transit;
    class Cloud_NAT,Internet egress;

  1. Intercept: An outbound request from a workload VM is intercepted via NSI and delivered over GENEVE to nic1.

  2. Inner Routing & SNAT: Inside PAN-OS, the packet is decapsulated. PAN-OS inspects the payload and routes it internally to nic2 (Untrust Zone). The firewall applies Source NAT (SNAT), translating the source address to nic2’s local IP address (10.250.10.5).

  3. Direct Egress: The unencapsulated packet exits nic2 into the Egress VPC, passing through a central GCP Cloud NAT to reach the public internet. The Untrust VPC remains unattached from the NCC Mesh, guaranteeing a physical air-gap.

4. Multi-Tenant folder structure & governance

To enforce strict organizational isolation and regional data residency (e.g., locking resources strictly to me-central2), the landing zone utilizes a structured folder hierarchy:

Root Organization
└── Top-Level Folder: fldr-enterprise-ksa (Locked to me-central2)
    ├── Folder: _bootstrap (IaC state buckets & seed accounts)
    ├── Folder: _common (Central Network Hub & Palo Alto projects)
    └── Folder: _environment (Core Business Applications)
        ├── Folder: App - Family A
        │   ├── Folder: Production -> prj-appA-prod
        │   └── Folder: Non-Production -> prj-appA-dev
        └── Folder: App - Family B
            ├── Folder: Production -> prj-appB-prod
            └── Folder: Non-Production -> prj-appB-dev

Identity and access control

  • Human Operators: Authenticate natively via Workforce Identity Federation integrated with enterprise Entra ID (Azure AD). Access is granted exclusively via group-based RBAC mapped to granular Custom IAM roles.

  • Automated Systems & Machine Identities: Rely on Workload Identity Federation (WIF) using short-lived OIDC tokens. Static service account JSON keys are strictly prohibited by organizational policy.

5. Cross-Regional Disaster Recovery (DR) Architecture

To support active-passive cross-continental Disaster Recovery (e.g., Primary in me-central2, Secondary in us-east-4), the architecture deploys an independent, pre-warmed mirror of the networking core.

                  [ Global External Load Balancer ]
                         (Single Anycast VIP)
                                  │
             ┌────────────────────┴────────────────────┐
             │ (Active Traffic)                        │ (Automated DR Failover)
             ▼                                         ▼
   PRIMARY REGION: me-central2                RECOVERY REGION: us-east-4
┌─────────────────────────────────┐       ┌─────────────────────────────────┐
│ • NCC Mesh: hub-primary         │       │ • NCC Mesh: hub-dr              │
│ • Palo Alto Pool (Active)       │       │ • Palo Alto Pool (Pre-Warmed)   │
│ • GCE SQL Primary (Read/Write)  │       │ • GCE SQL Standby (Read-Only)   │
└────────────────┬────────────────┘       └────────────────▲────────────────┘
                 │                                         │
                 └────── SQL Always On Asynchronous ───────┘
                        (Private GCP Subsea Backbone)

Key DR operational mechanics:

  1. Database Mirroring: Self-managed SQL Server engines run on Compute Engine using SQL Server Always On Availability Groups in asynchronous commit mode. Transaction logs stream continuously across the private NCC interregional backbone.

  2. Disk Replication: Stateless application VMs utilize Cross-Region Persistent Disk Asynchronous Replication (PD Async Replication), continuously streaming storage delta changes to detached, standby disk targets in the DR region without incurring compute running costs.

  3. Automated Failover: Upon primary site failure, platform orchestration runbooks promote the standby SQL node to read-write, scale up the standby Managed Instance Groups (MIGs), and attach the pre-synchronized disks. The Global Load Balancer automatically shifts ingress traffic to the secondary region.

Conclusion

Combining GCP Network Security Intercept, NCC Mesh Topologies, and Palo Alto VM-Series Multi-NIC firewalls establishes a modern, highly scalable security blueprint. By decoupling route management from packet inspection, enterprise security teams can enforce strict Layer 7 inspection, preserve full client IP visibility, and support multi-region resilience—all while eliminating the operational friction of traditional cloud routing models.

6 Likes
6

Great write-up, Abhishek! Having overseen the actual implementation of this architecture with you at our client, I can attest to how powerful this setup is in production.

Moving away from complex static routing and eliminating mandatory SNAT for East-West traffic was a game-changer for preserving client IP visibility and simplifying incident response. The combination of GCP NSI and NCC Mesh Topology really delivers on reducing operational friction while maintaining a robust Zero Trust posture.

2 Likes