Professional Cloud Network Engineer

Planning the Firewall Strategy (VPC Firewall Rules, Cloud NGFW, Hierarchical Rules, and Third-Party Integration)

Planning a Google Cloud firewall strategy involves selecting the right combination of native distributed firewalls and third-party network virtual appliances to secure traffic across an organization. Organizations build a layered defense by combining broad organization-wide guardrails, project-level network policies, and workload-specific filtering. Native options include hierarchical firewall policies, global network firewall policies, regional network firewall policies, and legacy Virtual Private Cloud (VPC) firewall rules. When organizations require vendor-specific threat feeds, deep Layer 7 packet inspection, or parity with on-premises equipment, they integrate third-party firewall appliances into their architecture.

Third-party firewall solutions, such as FortiGate NGFW and Palo Alto Networks VM-Series, run as Compute Engine virtual machines (VMs) deployed in a hub-and-spoke architecture. In this design, a dedicated security VPC acts as a central transit hub that inspects north-south traffic entering from the internet, east-west traffic moving between workload VPCs connected via VPC Network Peering, and hybrid traffic arriving over Cloud Interconnect or Cloud VPN. Third-party appliance VMs use three distinct network interfaces: a management interface for administrative access, an untrust interface connected to external networks, and a trust interface connected to internal workload networks. To deliver high availability and horizontal scaling, multiple appliance instances are placed behind an Internal TCP/UDP Load Balancer with symmetric hashing enabled to maintain bidirectional session flow. While third-party appliances provide specialized vendor features, they introduce infrastructure management overhead and potential routing bottlenecks that native Cloud Next Generation Firewall (Cloud NGFW) avoids by enforcing rules directly at the VM hypervisor layer.

Understanding the Effective Policy Rules for Hierarchical Firewall Situations

Effective policy rules represent the final consolidated set of filtering rules evaluated on a virtual machine interface after processing the entire Google Cloud resource hierarchy. When network traffic enters or leaves an interface, the firewall engine evaluates rules top-down: first from the hierarchical firewall policy associated with the organization node, then from policies linked to nested folders, followed by global network firewall policies, regional network firewall policies, and legacy VPC firewall rules. Within each policy level, rules are evaluated in ascending order of their numeric priority, where 0 is the highest priority. Evaluation halts immediately when traffic matches an explicit allow or deny rule, whereas matching a goto_next rule delegates evaluation down to the next level in the hierarchy.

Resource ancestry determines how rules inherit in specialized network topologies:

• In a Shared VPC architecture, VM interfaces connected to a shared subnet inherit the hierarchical policies attached to the host project's folder hierarchy, completely bypassing the service project's folder policies.
• Across a VPC Network Peering connection, each peered network maintains independent policy hierarchies, meaning traffic is evaluated against the source network's policies upon egress and the destination network's policies upon ingress.
• Predefined rules at the lowest priority within hierarchical policies automatically pass unmatched packets down to lower policy tiers.
• Network administrators can query the full inheritance chain for any VM interface by running the gcloud compute instances get-effective-firewalls command.

Configuring Cloud NGFW to Support GKE and Cloud Load Balancing

Configuring Cloud NGFW for Google Kubernetes Engine (GKE) and Cloud Load Balancing establishes an in-line security boundary that inspects traffic before it reaches container workloads. An external or internal load balancer accepts traffic in a dedicated proxy-only subnet and directs requests to backend services pointing to Network Endpoint Groups (NEGs) containing GKE Pods. To enforce security inspection along this path, administrators attach a global network firewall policy to the VPC network containing both the proxy-only subnet and the GKE cluster subnets. The policy contains rules using the apply_security_profile_group action to intercept incoming packets and route them to managed firewall endpoints for threat prevention and URL filtering before standard allow rules permit delivery to the Pods.

GKE clusters achieve defense-in-depth by combining node-level Cloud NGFW rules with pod-level Kubernetes network policies. While VPC firewalls secure traffic at the VM node hypervisor, network policies control pod-to-pod communication within the cluster using pod labels and namespace selectors. Enabling GKE Dataplane V2 provides built-in network policy enforcement powered by eBPF without requiring additional CNI plugins, and it supports policy auditing through network logging custom resource definitions. Private GKE clusters use Private Google Access over reserved addresses (199.36.153.8/30 or 199.36.153.4/30) to reach Google APIs privately, while outbound internet traffic passes through Cloud NAT, which should be configured to prevent unnecessary double source network address translation (SNAT) on GKE nodes.

Creating and Troubleshooting VPC Firewall Rules and Cloud NGFW Regional, Global, and Hierarchical Policies

Creating and troubleshooting firewall rules requires understanding policy scoping, connection tracking mechanics, and priority-based evaluation sequences. Legacy VPC firewall rules operate as distributed, stateful packet filters directly at each VM hypervisor, supporting priorities from 0 to 65535 and automatically tracking bidirectional sessions for up to 10 minutes of inactivity. Hypervisor connection tables support 130,000 connections on shared-core instances, 130,000 connections per vCPU on instances with 1 to 8 vCPUs, and up to 1,040,000 total connections on machines with more than 8 vCPUs. In high-performance computing environments, Remote Direct Memory Access over Converged Ethernet (RoCE) VPC networks enforce unique constraints by supporting only stateless regional network firewall policies (RDMA_ROCE_POLICY), requiring explicit ingress rules in both directions.

Troubleshooting firewall enforcement relies on identifying shadowed rules, policy conflicts, and dropped connections across layers:

• A shadowed rule occurs when a higher-priority, broader rule matches traffic first, preventing a lower-priority specific rule from ever executing.
• Firewall Insights analyzes traffic telemetry over a 30-day window to identify shadowed rules, unused allow rules, and unneeded port definitions.
• Network Intelligence Center Connectivity Tests simulates packet routes between endpoints to display every evaluated firewall rule along the path without sending live traffic.
• Under the default BEFORE_CLASSIC_FIREWALL setting, global and regional network firewall policies evaluate before legacy VPC firewall rules, whereas the AFTER_CLASSIC_FIREWALL setting reverses this order.

Enabling Layer 7 Packet Inspection with Cloud NGFW Enterprise

Cloud NGFW Enterprise enables deep Layer 7 packet inspection and advanced threat prevention across VPC networks without requiring routing changes or virtual appliances. The service uses packet interception technology powered by Palo Alto Networks threat prevention engines to scan payloads for vulnerabilities, spyware, and viruses. Administrators configure a security profile of type threat-prevention to customize signature actions and assign it to an organization-level or project-level security profile group.

To activate Layer 7 inspection, an administrator provisions a zonal firewall endpoint in the target workload zone, establishes a firewall endpoint association between the endpoint and the VPC network, and attaches an optional Transport Layer Security (TLS) inspection policy backed by a Certificate Authority Service pool to decrypt traffic. Firewall policy rules match traffic and apply the apply_security_profile_group action with the --tls-inspect flag to redirect packets through the endpoint. If the firewall endpoint encounters an operational failure or incomplete configuration, the system executes a fallback action of allow to prevent unintended workload outages.

Migrating from VPC Firewall Rules to Cloud NGFW Policies

Migrating from legacy VPC firewall rules to Cloud NGFW policies consolidates disparate rule sets into centrally governed network firewall policy objects. The VPC firewall rules migration tool automates this transition by analyzing existing network configurations, converting legacy rules into a unified global network firewall policy, and associating the new policy with the VPC network.

During the migration process, the tool assigns distinct integer priorities to every rule to resolve priority overlap. If multiple legacy VPC rules share the same priority score, the migration tool automatically assigns a higher priority (a lower integer) to deny rules over allow rules to preserve the organization's existing security posture. Migrating to global network firewall policies enables advanced capabilities such as IAM-governed secure tags, fully qualified domain name (FQDN) filtering, and batch rule updates that legacy VPC rules do not support.

Configuring VPC and NGFW Rule Criteria

Configuring firewall rule criteria defines the exact matching conditions, direction, priority, and actions that govern network traffic. Every rule specifies a direction—either ingress for inbound packets or egress for outbound packets—and an action of allow, deny, goto_next, or apply_security_profile_group. Priority scores dictate evaluation order, ranging from 0 to 65535 for VPC firewall rules and 0 to 2147483647 for Cloud NGFW policies.

Rule matching conditions filter traffic based on Layer 4 protocols and destination ports:

• Supported protocols include TCP, UDP, ICMP, SCTP, ESP, AH, and IPIP.
• Google Cloud firewall rules match exclusively on destination ports and do not evaluate source ports.
• Source and destination IP criteria accept IPv4 and IPv6 CIDR ranges, though a single legacy VPC firewall rule cannot mix both address families.
• If traffic matches no custom rules, the firewall enforces implicit default rules: an implied allow rule for all egress and an implied deny rule for all ingress.

Configuring VPC and Firewall Rules Logging

Firewall Rules Logging captures real-time connection telemetry whenever network traffic matches a configured firewall rule. Administrators enable logging on individual allow or deny rules within VPC firewall rules, network firewall policies, or hierarchical policies, though logging is not supported on goto_next rules. When enabled, connection metadata—including 5-tuple packet details, match status, and timestamps—is exported directly to Cloud Logging.

Logged events integrate with centralized monitoring and security management platforms:

• Security Command Center (SCC) and Google Security Operations (Google SecOps) ingest firewall logs and Cloud NGFW threat findings to correlate security events and trigger automated mitigation playbooks.
• Firewall Insights analyzes log hit counts to discover unused rules and optimize firewall rule efficiency.
• Log aggregation across Shared VPC architectures allows central network teams to audit all ingress and egress flows from a single management project.

Incorporating Micro-Segmentation for Security Purposes

Micro-segmentation isolates workloads and restricts lateral movement within Google Cloud networks using resource identities and metadata rather than static IP addresses. Organizations implement segmentation through several targeting mechanisms:

• Network tags are simple text labels applied to VMs for legacy VPC firewall rules, but they lack IAM controls and do not work with hierarchical policies.
• Service accounts bind firewall rules to a VM instance's runtime identity, ensuring that only workloads running under an authorized service account can communicate across subnets or Shared VPC environments.
• Secure tags are centrally governed key-value pairs managed by IAM that attach to VM instances and enforce granular access controls across hierarchical policies, network policies, and VPC Network Peering boundaries.
• Cloud NGFW Standard objects—such as address groups, fully qualified domain name (FQDN) objects, and geolocation objects—allow policies to dynamically filter traffic based on domain names, curated IP lists, or geographic regions.

Differentiating Between the Different Tiers of Cloud NGFW: Essentials, Standard, and Enterprise

Cloud NGFW provides three service tiers tailored to different security, threat intelligence, and traffic inspection requirements:

• Cloud NGFW Essentials delivers baseline stateful firewall capabilities, supporting global and regional network firewall policies, hierarchical policies, secure tags, and policy enforcement ordering across VPC networks.
• Cloud NGFW Standard builds upon Essentials by adding advanced policy objects and threat intelligence, including Google Threat Intelligence lists, FQDN filtering, geolocation objects, and reusable address groups.
• Cloud NGFW Enterprise includes all Standard capabilities and adds managed Layer 7 packet inspection, TLS forward proxy decryption, URL filtering, and intrusion detection and prevention service (IPS) engines powered by Palo Alto Networks technologies.

Key Facts

• Cloud NGFW evaluates firewall rules in a top-down hierarchy: hierarchical policies evaluate first, followed by global network firewall policies, regional network firewall policies, and legacy VPC firewall rules.
• The goto_next rule action skips remaining rules within the active policy layer and delegates packet evaluation down to the next policy level in the hierarchy.
• Stateful VPC firewall rules support up to 130,000 connections on shared-core instances, 130,000 connections per vCPU on 1 to 8 vCPU instances, and a maximum of 1,040,000 connections on instances with more than 8 vCPUs.
• In a Shared VPC architecture, VM interfaces connected to shared subnets inherit hierarchical firewall policies from the host project's folder hierarchy, not the service project's folder hierarchy.
• Cloud NGFW Enterprise uses the apply_security_profile_group action to route packets to zonal firewall endpoints for Layer 7 inspection and defaults to an allow fallback action if the inspection endpoint fails.

Frequently Asked Questions

What is the difference between network tags and secure tags?

Network tags are user-defined text strings configured directly on VM instances that lack IAM access governance and only apply to legacy VPC firewall rules. Secure tags are centralized key-value resources governed by IAM permissions that can be applied across hierarchical, global, and regional firewall policies to enforce micro-segmentation across peered VPC networks.

How does the rule enforcement order setting change firewall evaluation?

Under the default BEFORE_CLASSIC_FIREWALL setting, global and regional network firewall policies are evaluated before legacy VPC firewall rules. Under the AFTER_CLASSIC_FIREWALL setting, legacy VPC firewall rules are evaluated before global and regional network firewall policies, though hierarchical policies always evaluate first under both settings.

When should an organization choose Cloud NGFW Enterprise over third-party virtual appliances?

Choose Cloud NGFW Enterprise when you require fully distributed, cloud-native Layer 7 packet inspection and intrusion prevention enforced directly at VM interfaces without changing network routing topologies or managing VM chokepoints. Choose third-party virtual appliances when you must maintain vendor-specific threat intelligence, specialized deep application inspection features, or operational consistency with existing on-premises security appliances.