Professional Cloud Network Engineer
A Google Cloud High Availability VPN (HA VPN) gateway is a regional resource that provides encrypted hybrid connectivity with a 99.99% uptime service level agreement (SLA). The gateway uses two distinct interfaces, designated as interface 0 and interface 1, and assigns a unique external IP address to each. To qualify for the SLA, administrators must establish active VPN tunnels across both interfaces to the remote peer network. HA VPN supports IPV4_ONLY and IPV4_IPV6 stack types, with dual-stack deployments requiring Internet Key Exchange version 2 (IKEv2) for cryptographic negotiation.
The external on-premises or cloud environment connects to Google Cloud through a configured external peer VPN gateway resource. Google Cloud groups peer gateways into three redundancy models based on their physical network configuration:
StudyCerts
StudyCertsSINGLE_IP_INTERNALLY_REDUNDANT represents a single peer device that uses one external IP address on interface 0.TWO_IPS_REDUNDANCY represents two separate peer devices or a single dual-homed device using two external IP addresses on interfaces 0 and 1.FOUR_IPS_REDUNDANCY represents multi-device or cloud provider configurations, such as Amazon Web Services, that use four external IP addresses distributed across interfaces 0 through 3.Each tunnel created on the HA VPN gateway must match the specific interface identifier and external IP address of the external peer gateway. If an administrator mismatches interface pairings or pre-shared keys during setup, the IPsec security associations will fail to negotiate.
Dynamic routing for HA VPN topologies is managed exclusively by Cloud Router, which runs Border Gateway Protocol (BGP) sessions over link-local addresses. When creating a Cloud Router, administrators must assign a private autonomous system number (ASN) from either 64512 through 65534 or 4200000000 through 4294967294. This ASN applies to every BGP session on that router and cannot be modified after the router is provisioned. Additionally, a Cloud Router managing HA VPN tunnels cannot be shared with a Partner Interconnect VLAN attachment.
Dynamic route exchange relies on dedicated router interfaces paired with specific VPN tunnels. Each BGP session uses a /30 link-local IPv4 subnet, such as 169.254.0.1/30 and 169.254.0.2/30, to peer between Google Cloud and the on-premises gateway. As routes change, Cloud Router automatically advertises local Virtual Private Cloud (VPC) subnets and learns remote network prefixes. The dynamic routing mode of the VPC network determines whether Cloud Router advertises regional or global subnets to the peer.
Dynamic route path selection across dual HA VPN tunnels is controlled by configuring the advertised route priority on Cloud Router. The advertised route priority acts as the BGP Multi-Exit Discriminator (MED) metric to signal path preference to the peer router. When both BGP sessions advertise identical route priorities, Cloud Router uses Equal-Cost Multi-Path (ECMP) routing in an active/active design. This active/active configuration distributes egress traffic across both tunnels to maximize overall throughput and redundancy.
An active/passive topology uses asymmetrical route priorities to establish a deterministic primary path and a standby path. Administrators set a lower numerical route priority on the primary tunnel and a higher numerical value on the secondary tunnel. Cloud Router sends all outbound traffic through the tunnel with the lowest numerical metric. If the primary BGP session enters a down state, Cloud Router automatically shifts outbound traffic to the standby tunnel.
Data path troubleshooting identifies packet drops and performance degradation caused by Maximum Transmission Unit (MTU) mismatches along the VPN path. Encapsulating user packets into IPsec tunnels adds encryption and transport headers that expand overall packet sizes beyond the default MTU. When an unfragmented packet exceeds the supported path MTU, intermediate routers drop the packet, causing file transfer stalls and broken TCP connections. Administrators resolve this by standardizing MTU settings across all network hops and enabling TCP Maximum Segment Size (MSS) clamping to prevent fragmentation-related packet loss.
BGP troubleshooting isolates routing anomalies such as session flapping, peering down states, and missing network prefixes. Cloud Router requires each BGP session to link with a designated tunnel interface and use valid /30 link-local IP addresses from the 169.254.0.0/16 range. BGP sessions will fail to establish if the configured peer ASN, local ASN, or peer IP addresses do not match on both sides. Peering sessions also drop or stop learning routes if the peer network advertises more prefixes than the Cloud Router route limits allow.
Firewall rules and configuration validation ensure that underlying network layers allow VPN negotiation and data transfer. Google Cloud VPC firewall rules and on-premises firewalls must permit User Datagram Protocol (UDP) port 500 for IKE, UDP port 4500 for NAT traversal, and Encapsulating Security Payload (ESP) protocol traffic. In addition, firewalls must allow Transmission Control Protocol (TCP) port 179 and link-local address ranges so BGP keepalive packets can pass between peers. A VPN tunnel will remain inactive until the corresponding partner tunnel is fully configured on the peer gateway with matching IP addresses and IKEv2 settings.
Diagnosing IKE and IPsec failures involves isolating breakdowns in the two-phase handshake required to build an encrypted tunnel. Cloud Logging and Cloud Monitoring provide the operational metrics and log events needed to detect whether a tunnel fails during Phase 1 or Phase 2. Phase 1 establishes the authenticated IKE Security Association (IKE SA), while Phase 2 negotiates the Child Security Association (Child SA) used to encrypt data payload traffic. If either phase fails during the handshake, the VPN tunnel cannot transition into an established state.
Configuration discrepancies between the HA VPN gateway and the remote peer device represent the primary cause of negotiation failures. The pre-shared key (PSK) must match on both gateways, as any character mismatch causes immediate Phase 1 authentication rejection. Both gateways must also agree on identical IKE versions, encryption ciphers such as AES-GCM or AES-CBC, integrity hashing algorithms, and Diffie-Hellman groups. Finally, traffic selectors must match; if the on-premises peer specifies a local subnet that does not match the remote selector configured in Google Cloud, Phase 2 Child SA negotiation terminates.
Troubleshooting advanced architectures like HA VPN over Cloud Interconnect requires verifying underlying dependencies in a strict order of operations. The physical Interconnect connection and the VLAN attachment BGP session must be fully operational before the VPN layer can function. Administrators use the gcloud compute routers get-status command to verify that the base BGP session is healthy and advertising the HA VPN gateway IP addresses. Only after confirming that the lower-level transport network is stable should administrators investigate VPN-specific settings like the PSK, cipher suites, and Phase 2 traffic selectors.
64512 through 65534 or 4200000000 through 4294967294 and cannot be modified after creation.Advertised route priority functions as the BGP Multi-Exit Discriminator (MED) metric to determine which tunnel receives traffic. When both tunnels have identical route priorities, Cloud Router balances traffic across both links in an active/active ECMP setup; when one tunnel has a lower numerical value than the other, Cloud Router directs traffic to the lower-cost primary link in an active/passive setup.
Phase 1 establishes the IKE Security Association to build an authenticated, secure control channel between the two gateway endpoints. Phase 2 uses that secure channel to negotiate the Child Security Association, which defines the IPsec encryption algorithms and traffic selectors for actual data transit.
BGP sessions fail if firewall rules block TCP port 179, if the link-local IP addresses in the 169.254.0.0/16 range are misconfigured, or if the local and remote ASNs do not match on both routers. A failure can also occur if the peer router advertises more routes than the maximum prefix limit supported by Cloud Router.
Prepare and test your skills
Prepare and test your skills