>
    Strata Copilot
    Configure GCP NSI Overlay Support
    Focus
    Download PDF
    Focus
    1. Home
    2. VM-Series
    3. VM-Series Firewall on Google Cloud Platform
    4. Configure GCP NSI Overlay Support
    Download PDF
    VM-Series

    Configure GCP NSI Overlay Support

    Table of Contents

    Configure GCP NSI Overlay Support

    GCP NSI Overlay for VM-Series software firewalls enables direct packet egress, reducing costs and network hops for enhanced cloud security.
    Where Can I Use This?What Do I Need?
    • VM-Series
    • PAN-OS® 12.1.8 or later
    GCP NSI Overlay Support extends your VM-Series firewall deployments within Google Cloud Platform's Network Security Intercept (NSI) framework. This feature enables your VM-Series to operate in a bump-in-the-wire mode, providing advanced network visibility and security without requiring changes to your existing network routing policies.
    It introduces overlay functionality, allowing inspected packets to egress directly from your firewall rather than being hairpinned back to your consumer VPCs. This architecture operates on a producer-consumer model where your VM-Series firewalls act as the producer of security services, and your workloads are the consumers. This architecture helps you reduce overall deployment costs by centralizing egress for all your consumer VPCs.
    In your Google Cloud environment, GCP NSI transparently redirects traffic from your Workload VPCs to your VM-Series firewalls. This redirection is initiated by VPC firewall policies applying to a Security Profile Group (SPG) and Security Profile (SP) configured for Custom Intercept, directing traffic to an Intercept Endpoint Group (EPG) and Deployment Group (DPG).
    A forwarding rule then sends geneve-encapsulated traffic to an Internal Load Balancer (ILB), distributing it to your cross-zone deployed VM-Series instances. Your VM-Series firewalls, provisioned with management (nic0), trust (nic1), and untrust (nic2) network interfaces, decapsulate these Geneve packets for deep inspection. With NSI overlay support, inner routing is enabled, allowing your firewall to use its routing table to forward inspected traffic directly.
    Autoscaling is currently not supported in GCP NSI Overlay.

    Configure GCP NSI Overlay Support Using CLI

    This procedure details how to enable and configure GCP NSI Overlay Support on your VM-Series firewall. This feature allows your firewall to perform direct packet egress in a GCP NSI environment.
    This procedure assumes your VM-Series software firewall is already deployed within a GCP NSI environment and is running PAN-OS 12.1.8 or later.
    1. Follow steps 1–5 to configure your Google Cloud Network Security Integration (NSI) environment.
      While configuring your GCP environment for NSI, ensure that you configure nic0 as Management, nic1 as Trust, and nic2 as Untrust interfaces.
      Keep regional restrictions in mind during deployment. Your security endpoint placement rules and the target consumer workloads must reside in the same geographic region.
    2. Implement PAN-OS device configuration.
      Log in to your VM-Series firewall and configure the interfaces using the PAN-OS CLI.
      1. Assign all application workload VPC traffic to enter dynamically through nic1 (ethernet1/1).
        set network interface ethernet ethernet1/1 layer3 dhcp-client enable yes set network virtual-router default interface ethernet1/1 set zone Trust network layer3 ethernet1/1
      2. Configure overlay egress out of nic2 (ethernet1/2).
        set network interface ethernet ethernet1/2 layer3 dhcp-client enable yes set network virtual-router default interface ethernet1/2 set zone Untrust network layer3 ethernet1/2
      3. Disable the default route for the data plane interface.
        1. Enter set network interface ethernet1/1 layer3 config-type static no-default-route yes
        2. Replace ethernet1/1 with the actual interface connected to your Application VPCs.
      4. Commit the configuration changes.
    3. Configure Egress NAT.
      1. Configure the no-NAT rule for east-west Trust-to-Trust traffic.
        set rulebase nat rules no-nat-east-west from Trust to Trust set rulebase nat rules no-nat-east-west source any destination any service any
      2. Configure source NAT (SNAT) for north-south Trust-to-Untrust traffic.
        set rulebase nat rules egress-nat from Trust to Untrust set rulebase nat rules egress-nat source any destination any service any set rulebase nat rules egress-nat source-translation dynamic-ip-and-port interface-address interface ethernet1/2
      3. Commit the changes.

    Perform the GCP NSI Health Check

    1. If the producer project was configured with an internal load balancer and regional health checks, run the infrastructure deployment command.
      google_compute_region_health_check.main
    2. Ensuring your firewall instances can respond to Google Cloud probing requires the proper configuration of network management profiles, allowed IP ranges, and security policy rules. To enable HTTPS management capabilities on the firewall to allow GCP probing, execute the command:
      set network profiles interface-management profile gcp-lb-profile https yes
    3. Group the health check source addresses to permit incoming probes through the rulebase.
      set address gcp-lb-check-ip-1 ip-netmask 35.191.0.0/16 set address gcp-lb-check-ip-2 ip-netmask 130.211.0.0/22 set address gcp-lb-check-ip-3 ip-netmask 209.85.152.0/22 set address gcp-lb-check-ip-4 ip-netmask 209.85.204.0/22 set address-group gcp-lb-check-ips static [ gcp-lb-check-ip-1 gcp-lb-check-ip-2 gcp-lb-check-ip-3 gcp-lb-check-ip-4 ]
    4. Allow the GCP load balancer and Managed Instance Group (MIG) probe IP blocks within the management profile.
      set network profiles interface-management-profile gcp-lb-profile https yes set network profiles interface-management-profile gcp-lb-profile permitted-ip 35.191.0.0/16 set network profiles interface-management-profile gcp-lb-profile permitted-ip 130.211.0.0/22 set network profiles interface-management-profile gcp-lb-profile permitted-ip 209.85.152.0/22 set network profiles interface-management-profile gcp-lb-profile permitted-ip 209.85.204.0/22
    5. Retrieve the load balancer IP for your deployment and configure static routes so the firewall returns health check responses via ethernet1/1 (nic1).
      1. Run the following gcloud command to retrieve the forwarding rule IP:
        gcloud compute forwarding-rules list
      2. Use the returned IP address to configure the address object and loopback interface. For example, if the IP is 10.120.1.2:
        set address gcp-lb-fwd-rule-1 ip-netmask 10.120.1.2/32 set address-group gcp-lb-fwd-rules static [ gcp-lb-fwd-rule-1 ] set network interface loopback units loopback.1 ip gcp-lb-fwd-rule-1 set network virtual-router default interface loopback.1 set zone gcp-lb-check network layer3 loopback.1 set network interface loopback units loopback.1 interface-management-profile gcp-lb-profile set network virtual-router default routing-table ip static-route gcp-healthcheck-1 destination 130.211.0.0/22 interface ethernet1/1 nexthop ip-address 10.120.1.1 set network virtual-router default routing-table ip static-route gcp-healthcheck-2 destination 35.191.0.0/16 interface ethernet1/1 nexthop ip-address 10.120.1.1
    6. Configure the security policy rule to allow health check traffic.
      set rulebase security rules gcp-lb-check-allow from any to any set rulebase security rules gcp-lb-check-allow source gcp-lb-check-ips set rulebase security rules gcp-lb-check-allow destination gcp-lb-fwd-rules set rulebase security rules gcp-lb-check-allow application ssl set rulebase security rules gcp-lb-check-allow service application-default set rulebase security rules gcp-lb-check-allow action allow
    7. Once deployed, health check performance can be audited directly from the GCP environment via the gcloud CLI toolset:
      1. To verify the Internal Load Balancer backend health status:
        gcloud compute backend-services get-health backend-service-name --region=region --format="table(status.healthStatus[0].instance,status.healthStatus[0].healthState)"
      2. To verify the Managed Instance Group (MIG) detailed state:
        gcloud compute instance-groups managed list-instances mig-name --region=region --format="table(name,instanceHealth[0].detailedHealthState,currentAction)"

    Enable GCP NSI Overlay Support on the VM-Series Firewall

    1. Enable the GCP NSI inspection plugin.
      request plugins vm_series gcp nsi inspect enable yes
      This activates the core GCP NSI Overlay Support feature, allowing your firewall to process Geneve-encapsulated traffic for inspection.
    2. Verify the GCP NSI inspection status.
      show plugins vm_series gcp nsi status
    3. Verify Geneve encapsulation and decapsulation counters for traffic inspection.
      show counter global filter delta yes | match geneve
      Observe incrementing geneve_encap and geneve_decap counters to confirm your firewall is processing NSI-related traffic.
    4. Configure pod traffic visibility for GKE workloads.
      Complete the following to allow pod traffic to reach your firewalls in the producer project.
      1. Enable intranode visibility for pod-to-pod traffic.
        This may take some time to propagate if you enable it after the cluster is already running.
      2. Deploy the ip-masq-agent DaemonSet on all cluster nodes so the firewall can see pod-to-pod traffic.
        apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ip-masq-agent
  namespace: kube-system
  labels:
    k8s-app: ip-masq-agent
spec:
  selector:
    matchLabels:
      k8s-app: ip-masq-agent
  template:
    metadata:
      labels:
        k8s-app: ip-masq-agent
    spec:
      hostNetwork: true
      priorityClassName: system-node-critical
      tolerations:
        - operator: Exists
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: ip-masq-agent
          image: registry.k8s.io/networking/ip-masq-agent:v2.8.0
          args:
            - --masq-chain=IP-MASQ
            - --nomasq-all-reserved-ranges=false
            - --v=2
          securityContext:
            privileged: true
            capabilities:
              add: ["NET_ADMIN", "NET_RAW"]
          volumeMounts:
            - name: config
              mountPath: /etc/config
      volumes:
        - name: config
          configMap:
            name: ip-masq-agent
            optional: true
            items:
              - key: config
                path: ip-masq-agent
      3. Update the ip-masq-agent ConfigMap in kube-system to add the specific CIDRs to the nonMasqueradeCIDRs section, ensuring pod traffic reaches the firewall via the NSI fabric while maintaining original pod IPs.
        apiVersion: v1
kind: ConfigMap
metadata:
  name: ip-masq-agent
  namespace: kube-system
data:
  config: |
    nonMasqueradeCIDRs:
      - 0.0.0.0/0
      - 10.40.0.0/16  # Replace with your GKE Management/Control Plane subnet
    resyncInterval: 60s
      4. (Optional) To inspect inter-VPC traffic, configure Network Connectivity Center (NCC).

    Disable GCP NSI Overlay Support

    Use this procedure to deactivate GCP NSI Overlay Support on your VM-Series firewall.
    1. Disable GCP NSI inspection.
      request plugins vm_series gcp nsi inspect enable no
    2. Commit the configuration changes.

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