Integrating third-party network virtual appliances (NVAs) into Google Cloud allows organizations to add advanced security inspection, intrusion detection, and centralized access control across hybrid and multi-cloud environments. Network architects deploy NVAs to protect north-south traffic entering or leaving cloud environments and east-west traffic flowing between internal subnets and VPC networks. These appliances connect to on-premises data centers using Cloud VPN tunnels or Cloud Interconnect attachments, coordinating routing policies to maintain an end-to-end security boundary.
Appliance insertion describes the method used to direct network traffic through an NVA for security inspection before it reaches its destination. Traditional deployments use multi-NIC virtual machines, where each virtual network interface attaches to a separate VPC network, allowing an appliance to bridge and inspect traffic between isolated VPCs. Alternatively, supported Google Cloud regions allow topology-independent NVA deployment within a single VPC by using Cloud Load Balancing combined with policy-based routing (PBR). This policy-driven approach eliminates the complexity of managing multi-NIC interfaces by steering specific traffic matching user-defined route policies directly to load-balanced NVA instances.
A hub-and-spoke topology centralizes administrative services and security policy enforcement within a primary hub VPC that connects to multiple spoke VPC networks. Spoke networks host separated environments such as development and testing stages, while routing hybrid and inter-spoke communications through the hub. Network connectivity between spokes and the hub VPC is established using VPC Network Peering, Cloud VPN, Network Connectivity Center (NCC), or multi-NIC NVAs. Because standard VPC Network Peering does not allow transitive routing, architectures requiring spoke-to-spoke communication through a central inspection appliance must use Cloud VPN tunnels, NCC, or an NVA with multiple interfaces to achieve traffic transitivity.
Hybrid Network Endpoint Groups (hybrid NEGs) allow Google Cloud load balancers to distribute traffic directly to backend IP addresses and ports located in on-premises environments or external clouds. Envoy-based regional load balancers utilize a dedicated proxy-only subnet configured with the REGIONAL_MANAGED_PROXY purpose to establish connections to hybrid backend targets. Cloud Router must advertise the IP address range of the proxy-only subnet to the on-premises environment using Border Gateway Protocol (BGP) to ensure proper return routing. Administrators deploy hybrid NEGs into specific Google Cloud zones that minimize geographic latency to the external data center.
Hybrid network routing relies on dynamic BGP route exchanges coordinated by Cloud Router over Cloud VPN tunnels or Cloud Interconnect VLAN attachments. When organizations deploy multiple VLAN attachments within the same region, on-premises routers advertise prefixes with matching Multi-Exit Discriminator (MED) values to trigger equal-cost multipath (ECMP) routing using a 5-tuple hash. For secure transport requirements, an HA VPN over Cloud Interconnect architecture isolates encrypted traffic by using a dedicated Cloud Router configured with regional internal IPv4 addresses exclusively for IPsec tunnel endpoints. Custom route configurations and destination NAT policies coordinate traffic flows across the hybrid boundary.
Designing traffic steering architectures with custom routes means using static routes and policy-based routing (PBR) to control the path that network traffic takes through a VPC network, specifically to direct it through third-party NVAs for inspection or security enforcement. This involves configuring routes with priorities and next hops that differ from the default VPC routing table to insert appliances into the traffic flow.
A static route is a manually defined path for traffic to a specific destination IP range, with its next hop set to an internal passthrough Network Load Balancer. This load balancer distributes traffic across a scalable pool of backend NVA instances. The static route overrides the VPC's default subnet routes, forcing traffic for the defined destination prefix to first go to the load balancer and then to the NVAs. The route's priority determines its precedence over other routes, where a lower numerical value indicates higher priority. Traffic follows this sequence: it is sent from the source VM, matched to the static route, forwarded to the internal load balancer, and finally distributed to a healthy NVA backend based on the load balancer's traffic distribution policy.
Policy-based routing provides more granular control than static routes by allowing routing decisions based on packet attributes like source and destination IP addresses, not just the destination. You create a policy-based route with a specific priority, source IP range, destination IP range, and a next hop, which can also be an internal load balancer fronting NVAs. Google Cloud evaluates these routes in order of highest priority (lowest number). If a packet's characteristics match the highest priority policy-based route, it is sent to the defined next hop, and all lower-priority routes are ignored. A special skip-policy-based route can be configured with the NVA's interface IP as its target to skip all other policy-based routes for traffic exiting the NVA, preventing traffic loops.
Traffic symmetry means the forward and return paths for a connection pass through the same NVA, which is required for stateful inspection. Asymmetric routing, where paths differ, can cause connection failures. To achieve symmetry, the routing configuration on both sides of the NVA must be coordinated. When steering ingress traffic from a hybrid connection to an NVA using policy-based routes, you must also ensure that egress traffic from the NVA back to the source uses a skip route to follow the VPC table. When connecting multiple VPCs in a hub-and-spoke topology, you apply static routes in spoke VPCs pointing to the hub's NVA load balancer and use policy-based routes in the hub VPC to direct traffic between spokes through the NVA.
Several key considerations impact the design. The scale of the architecture is limited by VPC peering group quotas and the maximum number of forwarding rules per internal load balancer. Using VPC Network Peering is simpler but has scaling limits, whereas using Cloud VPN for transit between VPCs increases complexity and cost but can support more spokes. The choice between a single-NIC NVA model and a multi-NIC model changes the network topology and routing requirements. You must also plan for high availability by deploying NVAs across zones in a managed instance group behind the load balancer.
Configuring load balancing for NVAs in Google Cloud involves deploying load balancers that distribute traffic across a fleet of appliance VMs while maintaining high availability, session affinity, and seamless failover. The architecture typically uses a pair of NVAs configured in an active-passive high-availability cluster, with load balancers serving as the entry point for traffic and health checks continuously monitoring the active instance.
An internal passthrough Network Load Balancer distributes traffic to backends within a VPC network using Layer 4 TCP/UDP forwarding. For NVA deployments, this load balancer sits inside the VPC and receives traffic from workloads within Google Cloud, forwarding it to the active NVA instance for inspection. The internal passthrough Network Load Balancer binds to an internal IP address and forwards all traffic to the external network interface of the active NVA instance. Traffic flows from the internal load balancer to the NVA's internal interface, where the appliance inspects, filters, or logs the traffic before forwarding it to its destination. The load balancer uses health checks to determine which NVA instance is active, with the built-in probe responder on the NVA responding only when a cluster member is active.
An external passthrough Network Load Balancer handles traffic originating from the internet or external sources before it reaches the NVA cluster. This load balancer binds to external IP addresses and forwards inbound traffic to the external network interface of the active NVA instance. For architectures requiring inspection of north-south traffic, the external passthrough Network Load Balancer serves as the first hop, delivering traffic to the NVA for security inspection before the traffic proceeds to internal workloads. Because it is a passthrough load balancer, the NVAs terminate the TCP connection themselves rather than having the load balancer terminate and re-establish it, preserving the original client source IP address for logging and security analysis.
Health checks enable the load balancer to detect instance failures and route traffic only to healthy, responsive backends. The load balancer probes each NVA at regular intervals using TCP, HTTP, or HTTPS protocols configured in the health check definition. Only the active NVA instance in an active-passive cluster responds to these probes; the passive instance does not respond. When a failover occurs, the previously passive NVA becomes the new active instance and begins responding to health checks. The load balancer detects this status change within seconds and immediately begins forwarding traffic to the new active instance. The connection tracking feature maintains existing TCP connection state during the transition, allowing active sessions to continue without interruption.
Traffic reaches the NVA load balancers through custom static routes or policy-based routes configured on the VPC network. A static route specifies the next hop for traffic matching a particular destination range, pointing to the internal IP address of the internal passthrough Network Load Balancer. When workloads send traffic to destinations that require NVA inspection, the traffic matches the custom route and is forwarded to the load balancer, which then distributes it to the active NVA. Policy-based routing allows traffic classification based on attributes such as source IP, destination IP, protocol, or port, enabling selective inspection where only certain traffic flows through the NVA.
When NVAs serve as inspection points for hybrid traffic flowing between Google Cloud and on-premises environments, the load balancer must be configured to work with hybrid connectivity products. Traffic from on-premises locations reaches Google Cloud through Cloud VPN tunnels or Cloud Interconnect VLAN attachments, enters the VPC network, and is routed to the internal passthrough Network Load Balancer for delivery to the NVA. For architectures requiring load balancing to backends outside Google Cloud, such as on-premises NVAs, hybrid network endpoint groups can be used as load balancer backends. A hybrid NEG contains IP:Port endpoints that the load balancer reaches using hybrid connectivity products.
Session affinity ensures that once a client establishes a connection through the load balancer to an NVA, subsequent requests from that client route to the same NVA for the lifetime of the session. This is important for stateful inspection scenarios where the NVA maintains connection state information. Cloud Load Balancing supports several session affinity options, including client IP affinity, generated cookie affinity, and HTTP cookie affinity. For NVA deployments using active-passive clustering, the load balancer's session affinity works with the cluster's failover behavior, and the connection tracking feature helps sustain existing TCP connections by maintaining state information during the transition.
Static routes direct traffic to a specific destination IP range with a manually defined next hop, while policy-based routing allows you to define routing decisions based on packet attributes like source IP, destination IP, protocol, or port. Policy-based routing provides more granular control and is evaluated in priority order, with the highest priority match determining the next hop.
Traffic symmetry is required for stateful inspection because the NVA must see both the forward and return paths of a connection to maintain connection state. Asymmetric routing, where the paths differ, can cause connection failures because the NVA cannot track the session properly.
A skip-policy-based route is configured with the NVA's interface IP as its target and tells the system to skip all other policy-based routes for traffic exiting the NVA. This allows the traffic to follow the standard VPC routing table after processing, preventing traffic loops where packets would continuously re-enter the NVA.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts