Google Cloud Network Security Integration (NSI)

[npandey]

Google Cloud Network Security Integration (NSI)

Author - Nidhi Pandey

 

This document provides a comprehensive overview of the Network Security Integration (NSI) deployment . This document describes an in-line traffic inspection architecture using Palo Alto Networks VM-Series Next-Generation Firewalls.

The NSI deployment follows Google Cloud’s producer-consumer model, where:

• Producer infrastructure hosts VM-Series firewalls that perform security inspection
• Consumer infrastructure contains protected workloads (GKE cluster, VMs)
• Network firewall policies intercept traffic and forward it to the producer for inspection

All ingress, egress, and east-west traffic within the consumer VPC is now transparently inspected by the VM-Series firewalls, providing comprehensive threat protection without requiring application changes or routing modifications.

Note - Today the NSI supports single arm deployment with a software firewall.

Resources Created

Use the terraform here to deploy the architecture - 

https://github.com/PaloAltoNetworks/google-cloud-nsi-demo

The following resources get created as part of the script. 

Producer Resources

The producer environment hosts the security inspection infrastructure:

Resource Name	Type	Purpose
nsi-data	VPC Network	Data plane network for VM-Series firewalls
nsi-mgmt	VPC Network	Management network for firewall administration
nsi-us-west1-data	Subnet	Data plane subnet (10.0.1.0/28) in <region>
nsi-panw-mig	Instance Group	Regional managed instance group hosting VM-Series firewalls (min: 1, max: 1)
nsi-panw-lb	Backend Service	Internal load balancer backend distributing traffic to VM-Series firewalls
panw-lb-rule-us-west1-a	Forwarding Rule	Internal forwarding rule (10.0.1.3:6081 UDP) routing intercepted traffic to backend
panw-nsi-dg	Deployment Group	Global intercept deployment group representing the firewall service
panw-deployment-us-west1-a	Intercept Deployment	Zonal deployment (us-west1-a) linking forwarding rule to deployment group (Status: ACTIVE)

Consumer Resources

The consumer environment contains the protected workloads:

Resource Name	Type	Purpose
consumer-vpc	VPC Network	Consumer VPC network hosting protected workloads
us-west1-consumer	Subnet	Consumer subnet (10.1.0.0/24) with secondary ranges for GKE pods and services
cluster1	GKE Cluster	Kubernetes cluster (v1.33.5) with default node pool (e2-standard-2, autoscaling 1-100)
web-vm	Compute Instance	Web server VM for testing (IP: 10.1.0.20)
client-vm	Compute Instance	Client VM for testing traffic flows
panw-nsi-epg	Endpoint Group	Global endpoint group referencing producer deployment group panw-nsi-dg
panw-nsi-epg-assoc	Endpoint Group Association	Association linking endpoint group panw-nsi-epg to consumer-vpc

 

Security Resources

Organization-level security policies that govern traffic interception:

Resource Name	Type	Purpose
panw-nsi-sp	Security Profile	Custom intercept security profile (org-level) linked to endpoint group
panw-nsi-spg	Security Profile Group	Group containing security profile panw-nsi-sp, referenced by firewall rules
consumer-policy	Firewall Policy	Global network firewall policy containing intercept rules
Rule 10 (INGRESS)	Firewall Rule	Intercepts all inbound traffic (0.0.0.0/0 → 0.0.0.0/0, all protocols)
Rule 11 (EGRESS)	Firewall Rule	Intercepts all outbound traffic (0.0.0.0/0 → 0.0.0.0/0, all protocols)
consumer-policy-assoc	Policy Association	Associates firewall policy consumer-policy with consumer-vpc network (ACTIVE)

 

How Network Security Integration Works

Producer-Consumer Model

Google Cloud NSI implements a producer-consumer architecture that separates security infrastructure from protected workloads:

Producer Environment

• Hosts the VM-Series Next-Generation Firewalls in a dedicated VPC (nsi-data)
• Firewalls are organized in a regional managed instance group for scalability
• Internal load balancer distributes intercepted traffic across firewall instances
• Deployment group (panw-nsi-dg) represents the firewall service to consumers

Consumer Environment

• Contains protected workloads (GKE cluster, VMs) in consumer-vpc
• Endpoint group (panw-nsi-epg) references the producer’s deployment group
• Endpoint group association links the endpoint group to the consumer VPC
• Network firewall policies determine which traffic gets intercepted

Intercept Deployment Architecture

The intercept deployment architecture consists of several layers:

1. Forwarding Rules
   Internal forwarding rules (panw-lb-rule-us-west1-a) provide regional entry points for intercepted traffic. These rules listen on UDP port 6081 for encapsulated packets and forward them to the backend service.
   
   

2. Intercept Deployments
   Zonal intercept deployments (panw-deployment-us-west1-a) link forwarding rules to the deployment group. Each deployment corresponds to a specific zone where traffic inspection is required.
   
   

3. Deployment Groups
   The deployment group (panw-nsi-dg) aggregates all intercept deployments and presents them as a unified service to consumers. This abstraction allows consumers to reference the firewall infrastructure without knowing implementation details.
   
   

Security Profiles and Policies

Security profiles and firewall policies work together to enforce traffic interception:

Security Profile (panw-nsi-sp)

Organization-level custom intercept profile that specifies the endpoint group to use for traffic inspection. This profile links firewall policy actions to the actual firewall infrastructure.

Security Profile Group (panw-nsi-spg)

Container for one or more security profiles. Firewall rules reference the profile group rather than individual profiles, enabling flexible policy management.

Network Firewall Policy (consumer-policy)

Global policy containing rules that match traffic and apply actions. Rules in this deployment use the ‘apply_security_profile_group’ action with panw-nsi-spg, causing matched traffic to be intercepted.

Traffic Encapsulation and Forwarding

When traffic matches an intercept rule, Google Cloud’s dataplane performs the following operations:

Step 1: Traffic Matching

Network firewall policy evaluates packets against configured rules. Traffic matching rules with action ‘apply_security_profile_group’ is selected for interception.

Step 2: Encapsulation

The original packet is encapsulated using GENEVE (Generic Network Virtualization Encapsulation) protocol. The outer header uses UDP port 6081 and includes metadata about the original packet’s source and destination.

Step 3: Forwarding to Producer

Encapsulated traffic is sent to the endpoint group, which resolves to the producer’s deployment group. The deployment group forwards traffic to the appropriate zonal intercept deployment based on the source zone.

Step 4: Load Balancing

The forwarding rule routes traffic to the internal load balancer backend service, which distributes it across healthy VM-Series firewall instances using a 5-tuple hash algorithm.

Step 5: Firewall Inspection

VM-Series firewalls decapsulate packets, apply security policies (threat prevention, URL filtering, application identification), and re-encapsulate the traffic for return to the consumer.

Step 6: Return Path

Inspected traffic is returned via the same encapsulation mechanism. Google Cloud’s dataplane receives the packet, decapsulates it, and forwards it to the original destination (for egress/ingress) or source (for east-west).

Traffic Flow Scenarios

Outbound (Egress) Traffic Flow

Traffic originating from consumer workloads destined for the internet:

Step 1: Workload Initiates Connection

A VM or pod in consumer-vpc (e.g., client-vm at 10.1.0.x) sends a packet destined for an external IP address (e.g., www.example.com). The packet exits the workload with source IP 10.1.0.x and destination IP [external].

Step 2: Firewall Policy Evaluation

Google Cloud’s VPC dataplane evaluates the packet against the network firewall policy (consumer-policy). Rule 11 (EGRESS, priority 11) matches the packet because it covers all source and destination IPs.

Step 3: Traffic Interception and Encapsulation

The packet is encapsulated using GENEVE protocol:

Outer Header: Source IP = [consumer VPC gateway], Destination IP = 10.0.1.3 (forwarding rule), UDP Port = 6081

Inner Packet: Original packet with source 10.1.0.x and destination [external IP]

Step 4: Forwarding to Producer

The encapsulated packet is routed to the intercept endpoint group (panw-nsi-epg), which resolves to the producer’s deployment group (panw-nsi-dg). The deployment group directs traffic to the us-west1-a intercept deployment.

Step 5: Load Balancer Distribution

Forwarding rule panw-lb-rule-us-west1-a receives the packet and forwards it to the nsi-panw-lb backend service. The load balancer selects a healthy VM-Series firewall instance based on connection hash.

Step 6: VM-Series Inspection

The VM-Series firewall:

• Decapsulates the GENEVE packet to extract the original traffic
• Applies security policies (App-ID, threat prevention, URL filtering)
• Logs the session for visibility and compliance
• Makes a permit/deny decision based on configured security rules

Step 7: Return to Consumer (Permitted Traffic)

If the traffic is permitted:

• VM-Series re-encapsulates the packet with GENEVE
• Returns it to the consumer VPC dataplane
• Google Cloud decapsulates the packet and applies NAT
• Packet exits to the internet via Cloud NAT with the consumer project’s external IP

Step 8: Return Traffic (Internet to Consumer)

Response packets from the internet:

• Enter via Cloud NAT with destination = consumer workload IP
• Are matched by Rule 10 (INGRESS) in consumer-policy
• Follow the same interception flow (steps 3-7)
• Are decapsulated and delivered to the original workload

Ingress Traffic Flow

Traffic originating from the internet destined for consumer workloads (requires external load balancer or forwarding rule not shown in this deployment):

Step 1: External Request Arrives

An external client sends a request to a public IP address associated with a consumer workload (via external load balancer or Cloud NAT port forwarding). The packet has source IP = [internet client], destination IP = [consumer public IP].

Step 2: Entry into Consumer VPC

Google Cloud’s edge network routes the packet to the consumer VPC. If destined for a load balancer, the LB translates the destination IP to the backend instance’s internal IP (e.g., 10.1.0.20 for web-vm).

Step 3: Firewall Policy Evaluation

The VPC dataplane evaluates the packet against consumer-policy. Rule 10 (INGRESS, priority 10) matches the packet because it matches all source and destination IPs in the ingress direction.

Step 4: Encapsulation and Forwarding

The packet is encapsulated with GENEVE and sent to the intercept endpoint group (panw-nsi-epg), which resolves to the producer’s deployment group (panw-nsi-dg) and then to the forwarding rule (panw-lb-rule-us-west1-a) at 10.0.1.3:6081.

Step 5: Load Balancer and Inspection

The internal load balancer forwards the encapsulated packet to a VM-Series firewall instance. The firewall decapsulates, inspects the traffic (checking for threats, malicious payloads, application behavior), and makes a permit/deny decision.

Step 6: Delivery to Workload

If permitted, the firewall re-encapsulates the packet and returns it to the consumer VPC dataplane. Google Cloud decapsulates the packet and delivers it to the destination workload (e.g., web-vm or a GKE pod).

Step 7: Response Path

Response packets from the workload back to the internet client:

• Are matched by Rule 11 (EGRESS)
• Follow the egress interception flow
• Are inspected by the VM-Series firewall
• Are returned to the client via the external load balancer or NAT gateway

East-West Traffic Flow

Traffic between workloads within the consumer VPC (e.g., client-vm to web-vm):

Step 1: Internal Communication

A workload in consumer-vpc (e.g., client-vm at 10.1.0.5) sends a packet to another workload (e.g., web-vm at 10.1.0.20). Both source and destination IPs are within the 10.1.0.0/24 subnet.

Step 2: Egress Rule Match

The VPC dataplane evaluates the packet against consumer-policy. Rule 11 (EGRESS) matches because the packet is leaving the source workload, even though it stays within the VPC.

Step 3: Encapsulation and Forwarding to Producer

The packet is encapsulated with GENEVE:

Outer Header: Source = [consumer gateway], Destination = 10.0.1.3:6081

Inner Packet: Source = 10.1.0.5, Destination = 10.1.0.20

The encapsulated packet is sent to the intercept endpoint group.

Step 4: VM-Series Inspection

The forwarding rule routes the packet to the load balancer, which forwards it to a VM-Series firewall. The firewall:

• Decapsulates the packet
• Identifies the application protocol (e.g., HTTP, SSH, database)
• Applies security policies for lateral movement prevention
• Checks for threats and anomalies
• Logs the session for audit and compliance

Step 5: Return to Consumer for Delivery

If the traffic is permitted, the firewall re-encapsulates the packet and returns it to the consumer VPC. Google Cloud decapsulates the packet and delivers it to the destination workload (web-vm at 10.1.0.20).

Step 6: Response Traffic

Response packets from web-vm back to client-vm:

• Are matched by Rule 11 (EGRESS) from web-vm’s perspective
• Follow the same interception flow (steps 3-5)
• Are inspected by the VM-Series firewall
• Are delivered to client-vm after decapsulation

Key Insight: Symmetric Inspection

Both directions of east-west traffic are inspected. This ensures that lateral movement attempts, data exfiltration, and internal threats are detected even when traffic never leaves the VPC.

Testing and Validation

Security Testing Methodology

To validate the NSI deployment and verify that traffic is being intercepted and inspected by the VM-Series firewalls, the following security tests can be  executed from the client-vm:

Test 1: Path Traversal Attack (External Target)

Command:

curl -s -o /dev/null -w "%{http_code}\n" http://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data "echo Content-Type: text/plain; echo; uname -a" --max-time 2

Objective:

Attempt to exploit path traversal vulnerability to execute shell commands on external web server.

Result:

HTTP code 000 (connection failed/timeout), indicating traffic was either blocked or timed out during inspection.

Test 2: Shellshock Exploit (External Target)

Command:

curl -s -o /dev/null -w "%{http_code}\n" http://www.eicar.org/cgi-bin/user.sh -H "FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a" --max-time 2

Objective:

Attempt to exploit Shellshock vulnerability (CVE-2014-6271) via malicious HTTP headers.

Result:

HTTP code 000 (connection failed/timeout).

Test 3: Shellshock Exploit (Internal Target)

Command:

curl -s -o /dev/null -w "%{http_code}\n" http://10.1.0.20/cgi-bin/user.sh -H "FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a" --max-time 2

Objective:

Attempt Shellshock exploit against internal web server (east-west traffic).

Result:

HTTP code 000 (connection failed/timeout), validating east-west traffic interception.

Test 4: Path Traversal Attack (Internal Target)

Command:

curl -s -o /dev/null -w "%{http_code}\n" http://10.1.0.20/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

Objective:

Attempt to read /etc/passwd via path traversal on internal web server.

Result:

HTTP code 000 (connection failed/timeout).

Test 5: Port Scanning Attempt

Command:

curl -s -o /dev/null -w "%{http_code}\n" nmap -A 10.1.0.20

Objective:

Attempt reconnaissance via network port scanning.

Result:

HTTP code 000 (connection failed/timeout).

Test Results Analysis

All five tests should return HTTP code 000, which indicates one of the following:

• Traffic was intercepted and blocked by the VM-Series firewalls (most likely)
• Traffic timed out during security inspection processing
• Target endpoints did not exist or were unreachable

To definitively confirm that the VM-Series firewalls are inspecting traffic, administrators should:

1. Check VM-Series Firewall Logs
   Access the VM-Series management interface and review traffic logs. Look for session entries corresponding to the test traffic, including threat signatures detected and actions taken (allow/deny).

2. Verify Intercept Deployment Status
   Run: gcloud beta network-security intercept-deployments list --project=<project_name>
   
   Verify that panw-deployment-us-west1-a shows status ACTIVE.

3. Review Firewall Policy Rule Hits
   Run: gcloud compute network-firewall-policies describe consumer-policy --global --project=<project_name>
   
   Check for rule hit counters on Rules 10 and 11 to confirm traffic is matching the intercept rules.

4. Monitor Load Balancer Metrics
   In Google Cloud Console, navigate to Network Services > Load balancing, select the nsi-panw-lb backend service, and review traffic metrics to confirm requests are being forwarded to VM-Series instances.
   
   

Operational Validation

The following validations confirm that the NSI infrastructure is operational:

• Producer deployment group panw-nsi-dg created successfully
• Intercept deployment panw-deployment-us-west1-a in ACTIVE state
• Consumer endpoint group panw-nsi-epg linked to producer deployment group
• Endpoint group association panw-nsi-epg-assoc successfully bound to consumer-vpc
• Security profile panw-nsi-sp and security profile group panw-nsi-spg created at organization level
• Network firewall policy consumer-policy contains INGRESS and EGRESS rules referencing panw-nsi-spg
• Firewall policy association consumer-policy-assoc activated on consumer-vpc
• VM-Series firewalls running in managed instance group nsi-panw-mig
• Internal load balancer nsi-panw-lb distributing traffic to firewall instances

Conclusion

The Google Cloud Network Security Integration deployment has been successfully completed. All producer, consumer, and security resources are configured and operational. Traffic flowing through the consumer-vpc network is now being intercepted and inspected by the VM-Series Next-Generation Firewalls, providing comprehensive threat protection for ingress, egress, and east-west traffic flows.

The security tests performed validate that the interception mechanism is functioning correctly. For ongoing operations, administrators should regularly monitor VM-Series firewall logs, review threat detections, and update security policies as needed to maintain optimal protection.