Professional Cloud Network Engineer
Policy-Based Routing (PBR) enables Google Cloud Virtual Private Cloud (VPC) networks to steer traffic based on packet attributes such as source IP address ranges and protocol versions in addition to destination IP addresses. This routing capability directs specific traffic flows through security inspection systems, such as third-party Network Virtual Appliances (NVAs) or proxy gateways, before the traffic reaches its destination. By using internal passthrough Network Load Balancers as next hops, network architectures scale inspection workloads symmetrically without interrupting general communication.
Policy-based routes are evaluated early in the Google Cloud route selection lifecycle, immediately after special routing paths and before standard subnet routes. Google Cloud evaluates policy-based routes strictly by route priority, where a numerically lower number indicates a higher priority. When a packet arrives, the network matches it against the highest-priority policy-based route; if a match occurs and the route specifies an internal passthrough Network Load Balancer next hop, Google Cloud bypasses standard static or dynamic routes and delivers the packet directly to the load balancer.
Administrators can configure a policy-based route with a next hop set to skip other policy-based routes by specifying default routing behavior (--next-hop-other-routes="DEFAULT_ROUTING"). When this skip option is evaluated as the highest-priority match, Google Cloud ignores all other policy-based routes and advances packet evaluation to the regular subnet routes step. Assigning a unique priority to every policy-based route in a VPC network avoids unpredictable packet steering caused by internal tie-breaking mechanisms.
An internal passthrough Network Load Balancer operates as a specialized next hop for custom static routes and policy-based routes to distribute traffic across a pool of backend virtual machines. When configured as a next hop, the load balancer delivers all protocol traffic—including TCP, UDP, and ICMP—to healthy backend instances across all ports, regardless of the protocols configured on its forwarding rule or backend service. The load balancer preserves original packet headers without proxying, maintaining both client source IP addresses and destination IP addresses.
Next hop internal passthrough Network Load Balancers require specific architectural rules regarding forwarding rules and regional scope. The forwarding rule must use a dedicated internal IP address, because shared IP addresses (--purpose=SHARED_LOADBALANCER_VIP) are unsupported and silently drop traffic. Furthermore, cross-region traffic from virtual machines, Cloud VPN tunnels, or Cloud Interconnect attachments requires enabling global access on the load balancer forwarding rule; otherwise, traffic arriving from other regions is dropped.
Symmetric traffic inspection architectures route bidirectional traffic through the same backend appliance instance to preserve session state for stateful firewalls. When an internal passthrough Network Load Balancer acts as the next hop to a pool of NVA instances, Google Cloud uses symmetric hashing to ensure that packets belonging to the same connection flow reach the same backend appliance in both directions. This symmetric behavior eliminates the need to implement source network address translation (SNAT) on appliance instances for internal communications.
Deploying NVAs behind a next hop internal passthrough Network Load Balancer requires specific backend configurations to maintain proper packet forwarding:
StudyCerts
StudyCerts--can-ip-forward=True).Secure Web Proxy (SWP) deploys in a next hop routing mode (NEXT_HOP_ROUTING_MODE) to intercept and inspect outbound web requests without requiring client-side proxy settings. Administrators create policy-based routes to steer traffic originating from specific source IP ranges directly to the proxy instance. Because Secure Web Proxy is a regional resource, client workloads generating the traffic must reside within the same Google Cloud region as the proxy gateway.
To allow internal east-west traffic between VPC instances to bypass proxy inspection, an administrator must create a default routing policy-based route (--next-hop-other-routes="DEFAULT_ROUTING"). This default routing route must be configured with a higher priority (numerically lower value) than the policy-based route pointing to the Secure Web Proxy next hop. If the proxy policy-based route is assigned the highest priority without an overriding default routing rule, standard VPC subnet routing is bypassed, disrupting normal intra-network communication.
Troubleshooting traffic steering issues requires checking next hop operational states, route specificity constraints, and firewall rules. A custom static or policy-based route cannot use a destination prefix that is equal to or more specific than an existing local subnet route; attempting to create such a route generates a destination range error because subnet routes always take precedence. If a next hop internal passthrough Network Load Balancer experiences complete backend failure where all instances fail health checks, Google Cloud continues forwarding packets to the backend pool using standard traffic distribution rather than dropping the route entirely.
Connectivity validation must also confirm that ingress firewall rules on backend NVA instances allow the original client source addresses. Because the internal passthrough Network Load Balancer does not perform network address translation, packets arrive at backend VMs with unchanged source IPs, requiring permissive ingress firewall policies matching the client source ranges. When cross-region traffic drops unexpectedly, administrators must verify that global access is active on the next hop forwarding rule and confirm that route priorities across different spokes or paths do not create conflicting route evaluations.
The VPC routing table follows a strict evaluation hierarchy to determine which route handles a packet when multiple routes match a destination. The control plane evaluates routes in a fixed order: Policy-Based Routes take precedence first, followed by subnet routes, then dynamic routes learned through Border Gateway Protocol (BGP), and finally standard static routes.
The routing order hierarchy is a fixed evaluation sequence that Google Cloud applies to select a single path for packet delivery. Policy-Based Routes (PBRs) have the highest precedence in the routing hierarchy. If a packet matches the criteria of a policy-based route—such as source IP, destination IP, or protocol—the network forwards the packet directly to the specified next hop and skips all other route types. Only when no policy-based route matches the packet does the network proceed to evaluate standard routing table entries.
Subnet routes, dynamic BGP routes, and standard static routes form the subsequent tiers of the routing evaluation sequence:
Different route types can coexist within a VPC routing table as long as their destination IP ranges do not conflict across precedence tiers. When multiple routes within the same route type match a packet's destination, the network selects the most specific route using longest prefix match. For example, within static routes, a destination prefix of 10.1.2.0/24 is selected over 10.1.0.0/16 for traffic sent to 10.1.2.5. Longest prefix match resolution occurs only after the system determines the route type by following the fixed precedence hierarchy.
When the next hop of a matching route becomes unreachable, Google Cloud drops the packet rather than falling back to a lower-precedence route. For example, if a policy-based route matches a packet but its next-hop instance is stopped or unreachable, the packet is dropped even if a valid subnet route or dynamic BGP route exists for that destination. Route selection depends solely on the matching hierarchy, making the health and reachability of configured next hops essential for uninterrupted network traffic.
Policy-based routing uses 5-tuple matching criteria, route priority values, and internal passthrough Network Load Balancers to achieve deterministic packet handling. Matching rules can evaluate packet attributes including source IP ranges, destination IP ranges, and IP protocols to steer traffic away from default paths. Assigning distinct priority values to each policy-based route ensures that the VPC network evaluates traffic deterministically without relying on internal tie-breaking logic.
--next-hop-other-routes="DEFAULT_ROUTING" and a higher priority allows internal east-west traffic to bypass inspection and follow standard subnet routing.The packet is dropped immediately. Google Cloud does not automatically fall back to subnet routes, dynamic BGP routes, or static routes when the highest-precedence matching route has an unreachable next hop.
The load balancer uses symmetric hashing to direct both inbound and outbound packets of the same connection to the same backend appliance VM. This preserves the connection state on the firewall appliance and removes the need to configure source NAT.
Because policy-based routes take precedence over subnet routes, a route steering traffic to Secure Web Proxy would intercept all internal traffic if evaluated first. Configuring a default routing rule (DEFAULT_ROUTING) at a higher priority ensures normal intra-VPC subnet communication bypasses the proxy.
Prepare and test your skills
Prepare and test your skills