Professional Cloud Network Engineer
High Availability VPN (HA VPN) is a Google Cloud service that creates secure, redundant IPSec tunnels between a Google Cloud Virtual Private Cloud (VPC) network and an on-premises VPN gateway. An HA VPN deployment has two main components: the HA VPN gateway in Google Cloud and the peer VPN gateway on the on-premises side. Google Cloud represents the peer device as an external VPN gateway resource, which stores the remote device’s IP addresses and interface configuration. The HA VPN gateway automatically receives two external IP addresses—one for interface 0 and one for interface 1—so that a failure on one path does not break connectivity.
The external VPN gateway resource supports three redundancy types that depend on how many interfaces the peer device has. A single interface uses SWO_IP_INTERNALLY_REDUNDANT, two interfaces use TWO_IPS_REDUNDANCY, and four interfaces use FOUR_IPS_REDUNDANCY—the last is required when connecting to Amazon Web Services (AWS). Interface identification uses numeric IDs starting at 0, and the gcloud CLI infers the redundancy type from the number of interface IDs you provide.
To create an HA VPN gateway, you call the vpnGateways.insert method and specify the gateway name, the VPC network, and optionally the stack type (IPv4-only or dual-stack). Google Cloud assigns the two external IP addresses automatically and does not allow you to choose them manually. The peer VPN gateway resource is created using externalVpnGateways.insert, where you define the name, interface IDs and IP addresses, and the redundancy type. The IP addresses you configure must exactly match the actual addresses on your physical or virtual VPN device, or the tunnels will not establish.
A Cloud Router manages all BGP sessions for HA VPN tunnels and must be created in the same region as the HA VPN gateway. When creating the Cloud Router, you assign a Google Autonomous System Number (ASN) from a private range (64512–65534 or 4200000000–4294967294). The ASN cannot be changed later, so choose carefully. You can reuse an existing Cloud Router only if it is not already managing BGP sessions for a VLAN attachment associated with Partner Interconnect or for Cloud NAT.
VPN tunnels create the encrypted IPSec connections between each HA VPN gateway interface and a corresponding peer gateway interface. To achieve the 99.99% availability SLA, you must create two tunnels—one for interface 0 and one for interface 1. Each tunnel uses an IKE version (IKEv2 is recommended and supports IPv6), a pre-shared key that must match on both sides, and references to the gateway, peer gateway, and Cloud Router. The pre-shared key cannot be retrieved after creation, so record it securely.
After the tunnels are created, you establish BGP sessions over each tunnel to exchange routing information. Each session requires a router interface on the Google Cloud side using a link-local IP address from the 169.254.0.0/16 range (typically a /30), and a BGP peer configuration that specifies the peer’s link-local IP address and ASN. You can set an optional advertised route priority to influence routing when multiple paths exist.
The complete configuration follows this order: first create a custom VPC network and subnet, then create the HA VPN gateway, then create the external VPN gateway resource, then create a Cloud Router, then create the VPN tunnels, and finally configure the BGP sessions. You can perform these steps using the Google Cloud console, gcloud CLI commands, or the Compute Engine API.
HA VPN gateways use a dual-tunnel architecture to provide an availability SLA of 99.99% when both interfaces are used with redundant peer interfaces. An HA VPN gateway configured with only one active interface and tunnel does not qualify for an SLA. The connection to the on-premises network requires an external VPN gateway resource that defines the peer hardware deployment. Google Cloud supports four peer redundancy models:
StudyCerts
StudyCertsTWO_IPS_REDUNDANCY, where HA VPN interface 0 connects to peer interface 0 and HA VPN interface 1 connects to peer interface 1.SWO_IP_INTERNALLY_REDUNDANT, which provides a 99.9% availability SLA because the peer side lacks hardware redundancy.FOUR_IPS_REDUNDANCY with peer interfaces 0, 1, 2, and 3 for maximum redundancy.Dynamic routing with Cloud Router and the Border Gateway Protocol (BGP) is mandatory for all HA VPN topologies—HA VPN does not support static routes. The Cloud Router automatically exchanges route information between the VPC and the on-premises network, so manual route updates are not needed during link disruptions. For full VPC reachability across all regions, set the VPC dynamic routing mode to global.
BGP sessions use link-local IP addresses from a shared /30 subnet for IPv4 or from the fdff:1::/64 range for IPv6. Both sides must match stack types (IPv4, IPv6, or dual-stack). Routing behavior across the two tunnels can be:
HA VPN over Cloud Interconnect is a hybrid architecture that layers IPSec encryption over dedicated or partner private physical circuits. This satisfies regulations that require encryption in transit while keeping traffic off the public internet. The architecture has two tiers:
For HA VPN over Cloud Interconnect, the HA VPN gateway interfaces use internal regional IPv4 ranges sized between /26 and /29 with the purpose IPSEC_INTERCONNECT. Both VLAN attachments must use the same addressing format. Bidirectional Forwarding Detection (BFD) must not be enabled at the Cloud Interconnect tier, because it does not accelerate failure detection for encapsulated HA VPN tunnel traffic.
Tunnel health and BGP session status are monitored using Cloud Logging and Cloud Monitoring. Cloud Logging captures event logs for VPN tunnels and BGP sessions, while Cloud Monitoring provides metrics and dashboards. To evaluate connectivity, check for successful IKE and IPsec negotiations in the logs and verify that BGP sessions are in an established state. A BGP session that is not established means routes are not being exchanged, which will break traffic flow.
Failover tests validate the redundancy built into the HA VPN configuration. You manually bring down an active VPN tunnel or the peer gateway interface, then observe if traffic seamlessly switches to the remaining tunnel. Use Cloud Monitoring to watch for packet loss or latency spikes, and Cloud Logging to confirm that the failover triggered the expected BGP route withdrawal and re-advertisement on the backup path. A successful test proves the design provides the intended availability.
When connectivity or performance issues arise, examine Cloud Logging for error messages such as IKE authentication failures, dead peer detection timeouts, or BGP hold timer expiries that pinpoint where the handshake or session failed. Simultaneously, review Cloud Monitoring metrics like tunnel traffic bytes and packet counts to see if the failure correlates with a drop to zero. This combined analysis helps determine if the problem is on the Google Cloud side (e.g., a misconfigured Cloud Router), the on-premises peer side, or the underlying network path.
Common problems often involve mismatched configurations or resource failures. If a VPN tunnel shows as down, verify that the pre-shared keys, IKE versions, and IP addresses match on both ends. If BGP sessions flap, check for incorrect subnet masks on the BGP peer IP addresses or ASN mismatches. For performance issues, ensure the tunnel's Maximum Transmission Unit (MTU) aligns with the VPC network's MTU setting. The troubleshooting flow starts at the tunnel state, moves to BGP session details, and then examines the specific error logs for each component.
Border Gateway Protocol (BGP) is the dynamic routing protocol that HA VPN uses to automatically exchange route information between VPC networks. A BGP session is a peering relationship established between a Cloud Router and a peer gateway, where each VPN tunnel requires its own BGP session to exchange routing information. You create these sessions by adding a BGP interface to the Cloud Router for each tunnel and then adding a BGP peer that specifies the Cloud Router's BGP IP address, the peer's IP address, and the peer's Autonomous System Number (ASN).
BGP determines the best path for traffic based on attributes like AS path length and local preference. To control path selection, you manipulate the advertisedRoutePriority (BGP local preference) on each BGP session. For active-standby configurations, you set a higher priority value (such as 100) on the primary session and a lower value (such as 90) on the standby session, making the primary path preferred. For active-active load sharing, you set the same priority on all sessions, allowing BGP to distribute traffic evenly across both tunnels. The Cloud Router installs learned routes into the VPC routing table as dynamic routes, which are then used to forward traffic through the appropriate VPN tunnel.
When connecting two Google Cloud VPCs via HA VPN, each Cloud Router advertises the IP prefixes of its local VPC subnets to its peer and learns the remote VPC's prefixes. The BGP peering IP addresses must be within the reserved link-local range (169.254.x.x/30) and must not conflict between the two sides. If one VPN tunnel or peer gateway becomes unavailable, BGP withdraws the route learned via that path, and traffic automatically fails over to the remaining healthy tunnel based on the next best available path in the routing table.
High-Availability Cloud VPN (HA VPN) provides encrypted IPsec connectivity between Google Cloud VPC networks with an availability service level agreement (SLA) of up to 99.99%. HA VPN uses the vpn-gateway API resource and requires dynamic routing with BGP, unlike Classic VPN which uses static routing. To connect two VPC networks directly, you deploy an HA VPN gateway in each VPC network and interconnect them across redundant VPN tunnels, ensuring that primary and secondary subnet IP address ranges do not overlap.
To achieve the 99.99% availability SLA, you need a specific topology with two Cloud VPN gateways and four distinct VPN tunnels. Both HA VPN gateways must reside in the same Google Cloud region, with each gateway automatically allocating two external IP addresses from distinct address pools (one for interface 0 and one for interface 1). You must configure two VPN tunnels per gateway, matching interface 0 to interface 0 and interface 1 to interface 1 on the peer gateway. Both gateways must share identical IP stack types, such as dual-stack IPV4_IPV6 or IPv4-only. Operating with only a single active tunnel invalidates the 99.99% SLA.
Cloud Router instances manage the BGP sessions for both tunnels in each VPC network. When a VPC network uses regional dynamic routing mode, Cloud Router advertises and learns routes only for subnets within its own region. When using global dynamic routing mode, Cloud Router advertises subnets across all regions and propagates learned routes to every subnet in the VPC. To maintain deterministic path selection, Cloud Router should advertise the same prefixes across both VPN links while applying base advertised route priorities to set primary and backup paths.
For cross-project connectivity, the peer project owner must grant the compute.vpnGateways.use IAM permission on the target HA VPN gateway before the connection can be established. Once permissions are granted and both gateways are deployed, BGP peering sessions establish dynamic routing over the encrypted tunnels, allowing private data to flow securely between distinct organizational perimeters.
HA VPN Gateway is Google's solution for creating highly available site-to-site IPsec VPN connections between Google Cloud VPC networks or between Google Cloud and on-premises networks. The service provides a 99.99% availability SLA when properly configured with two HA VPN gateways in the same region, each with two tunnels connecting corresponding interfaces. When gateways are in different regions, the SLA drops to 99.9%.
For GCP-to-GCP connectivity, you deploy an HA VPN gateway in each VPC network. The highest availability is achieved when both gateways are in the same region, even when the VPC networks span multiple regions, since VPC networks are global resources that can span regions regardless of gateway placement. You must configure Tunnel 0 to connect interface 0 on one gateway to interface 0 on the peer gateway, and Tunnel 1 to connect interface 1 to interface 1. This cross-interface pairing ensures that if one interface fails, the other interface's tunnel maintains connectivity.
Google provides two primary routing configurations: active-passive and active-active. With a single HA VPN gateway, active-passive routing is recommended because the bandwidth capacity remains constant during normal operation and failover. When using multiple HA VPN gateways, active-active routing provides double the maximum bandwidth capacity during normal operation, but this configuration can cause dropped traffic during failover events. A critical caution applies to active-passive configurations with more than two tunnels: HA VPN does not use the passive tunnels for failover until all active tunnels on all gateways have failed.
Monitoring HA VPN involves using Cloud Logging and Cloud Monitoring metrics to track tunnel status and BGP session health. Key metrics include tunnel status, number of connections per gateway, and packet counts for received and transmitted traffic. Cloud Logging captures detailed events related to tunnel state changes, IKE negotiations, and BGP session updates. Connectivity failures typically stem from mismatched IKE security parameters (encryption algorithms, authentication methods, or pre-shared keys) or BGP advertisement issues (incorrect ASN configuration, missing MD5 authentication matches, or interface IP address conflicts).
Connectivity Tests in Network Intelligence Center help diagnose failures by tracing packet paths through the network. The test performs seven key checks: verifying the source VM can send egress packets, performing spoof checks on IP addresses, evaluating egress firewall rules, matching routes for the destination IP address, verifying ingress firewall rules allow the packet, running spoof checks on the destination VM, and confirming the destination VM can receive packets. Test results show whether packets were delivered or blocked at each checkpoint with specific failure reasons.
Configuring IKE Security Associations, ciphers, and network firewalls involves setting up the cryptographic parameters and firewall rules that protect site-to-site IPsec VPN connections between Google Cloud and on-premises or other cloud networks. The Internet Key Exchange (IKE) protocol establishes secure communications by negotiating security associations (SAs) between VPN endpoints, while firewall rules must permit the specific protocols and ports that IPsec requires to function.
Google Distributed Cloud (GDC) VPN supports IKEv2 using an IKE pre-shared key (PSK) as the sole authentication method. When creating a VPN tunnel, you specify a pre-shared key, and the peer VPN gateway must be configured with the exact same key to successfully authenticate the connection. This shared secret serves as the basis for establishing trust between the two VPN endpoints before cryptographic parameters are negotiated. In hybrid cloud deployments, such as connecting AWS to Google Cloud, you download the peer configuration to extract this pre-shared key and IKE version for consistent setup on both sides.
GDC VPN only supports site-to-site IPsec VPN connectivity. The peer VPN gateway must have a static external IPv4 address to establish the connection. If the peer gateway is behind a firewall, you must configure rules to pass both the Encapsulating Security Payload (ESP) IPsec protocol and IKE traffic on UDP ports 500 and 4500. UDP port 500 is for initial IKE negotiations, while UDP port 4500 is for NAT-Traversal (NAT-T), which allows the VPN to work through network address translation. On the cloud side, such as AWS, security group inbound rules must allow all protocols and ports from the Cloud VPN IP address range to permit traffic flow through the tunnel.
GDC VPN supports ESP in tunnel mode with authentication. Tunnel mode encapsulates the entire original IP packet within a new IPsec packet, providing complete protection for the traffic. The service does not support Authentication Header (AH) or ESP in transport mode. Each GDC VPN tunnel achieves a throughput of up to 600 Mbps. The VPN supports one-to-one NAT using UDP encapsulation for NAT-T, and the peer gateway must identify itself using its static external IPv4 address, not its internal private IP, for proper NAT-T functionality.
In hybrid cloud deployments, VPC firewall rules must be configured on both sides to permit the IPSec control plane traffic and the routed payload traffic. For Classic VPN configurations using static routing, you add the remote network IP ranges from the peer VPN configuration into the Cloud VPN tunnel settings. The firewall rules on both cloud platforms must align with the CIDR ranges being advertised over the VPN. When using dynamic routing with HA VPN, firewall rules must also match the imported routes from VPC Peering connections, such as allowing traffic on specific ports for database access.
GDC VPN supports dynamic routing through IPv4 BGP sessions for each VPN tunnel, enabling BGP peers to advertise routes to each other automatically. Each BGP session requires IPv4 addresses belonging to the same /30 subnet within the 169.254.0.0/16 range. The BGP keepalive interval is 30 seconds with a hold timer of 90 seconds. MD5 authentication is not supported for BGP sessions. To create a VPN BGP session, you create a VPNBGPPeer object with the remote and local peer specifications, including IP addresses and Autonomous System Numbers (ASNs), enabling dynamic route exchange between networks.
Routing architectures establish how traffic traverses hybrid connections between Google Cloud Virtual Private Cloud (VPC) networks and remote peer environments. When connecting hybrid networks using Classic Cloud VPN, administrators configure tunnels using either static routing or dynamic Border Gateway Protocol (BGP) routing managed by Cloud Router. Selecting the appropriate architecture depends on peer device capabilities, network topology scale, and whether routing decisions are bound to explicit static paths or dynamically exchanged control plane advertisements.
Static routing directs VPC network traffic toward a remote network by defining fixed routes that point to a specific Classic VPN tunnel as the next hop. A static route applies by default to all virtual machines (VMs) across all regions within the VPC network. Administrators can restrict the applicability of a static route to specific workloads by configuring network instance tags during route creation. Choose static route-based architectures when connecting to peer VPN gateways that lack dynamic routing capabilities or when specific VM-level routing isolation is required via instance tags.
Dynamic routing uses Cloud Router as an external BGP (eBGP) speaker to exchange network reachability information automatically between Google Cloud and peer networks. Cloud Router operates strictly within the control plane and programs routes into the Google Cloud software-defined network (SDN). Network administrators can configure Cloud Router in either regional or global routing modes to control subnet advertisement boundaries. In regional mode, Cloud Router advertises only local subnets within its region, whereas global mode advertises all subnets across the VPC network while applying a Multi-Exit Discriminator (MED) metric penalty for cross-region routes.
Architectural selection between static route-based routing and dynamic routing depends on network scalability, routing symmetry requirements, and configuration management overhead. Static routing allows granular VM targeting using instance tags but introduces administrative burden because path changes and route updates must be manually provisioned. Dynamic routing automates path updates and enforces symmetrical regional transit paths by using regional metric penalties, but it does not support tag-based route filtering. For scalable and automated route synchronization, dynamic routing via Cloud Router is the standard best practice across supported hybrid topologies.
Diagnosing VPN tunnel connectivity begins with investigating the Internet Key Exchange (IKE) handshake failures for Phase 1 (IKE SA establishment) and Phase 2 (IPsec SA establishment). You use Cloud Logging and Cloud Monitoring to inspect logs and metrics for these failures. The logs provide detailed error codes and status messages indicating why the handshake did not complete, such as mismatched pre-shared keys, incompatible encryption algorithms, or unreachable peer IP addresses. Monitoring allows you to track the health and state of VPN tunnels over time, identifying intermittent failures that could affect redundancy.
Classic VPN gateways have inherent redundancy and performance limitations that directly impact their SLA. A single Classic VPN gateway provides only a 99.9% availability SLA, as it relies on a single instance without built-in high availability. Its maximum throughput is capped at 3 Gbps, which can become a bottleneck for data-intensive hybrid connections. In contrast, HA VPN is designed for high availability, offering a 99.99% SLA when configured with two active interfaces and tunnels. Evaluating these constraints is critical when diagnosing why a Classic VPN tunnel might fail to meet performance or uptime requirements.
A key part of diagnosing limitations is evaluating the redundancy architecture. A Classic VPN deployment is a single point of failure; if its sole gateway or tunnel fails, the entire connection is lost. To achieve higher availability, you must migrate to HA VPN. The migration pathway involves creating new HA VPN gateways and tunnels, reconfiguring BGP sessions on a new Cloud Router, and updating on-premises peer gateway configurations. HA VPN over Cloud Interconnect is a supported pattern that combines encryption with private backbone connectivity, further illustrating the architectural shift required for improved redundancy.
Operational constraints for Classic VPN include the inability to use internal IP addresses for gateways and no support for IPv6 traffic. When diagnosing connectivity, you must verify that all cryptographic parameters (IKE version, encryption algorithms, Diffie-Hellman groups) match exactly between the Google Cloud gateway and the on-premises peer device. Cloud Logging provides the specific logs for these negotiations. Understanding that Classic VPN is a legacy service helps explain its limitations compared to the modern HA VPN, guiding your troubleshooting focus and long-term remediation plans.
IPSEC_INTERCONNECT, and BFD must not be enabled at the Cloud Interconnect tier.Active/active routing uses equal BGP metrics so that traffic load-balances across both tunnels via Equal-Cost Multipath. Active/passive routing uses different metrics so that the standby tunnel only carries traffic if the primary tunnel fails, ensuring a clear failover path.
To qualify for the 99.99% SLA, you must configure two VPN tunnels—one for each interface of the HA VPN gateway—and connect each tunnel to a redundant peer interface. For cloud-to-cloud connectivity, you need two HA VPN gateways in the same region, each with two tunnels connecting corresponding interfaces; if gateways are in different regions, the SLA drops to 99.9%.
Use static routing when connecting to peer VPN gateways that lack dynamic routing capabilities or when you need to restrict routes to specific VMs using instance tags. Use dynamic routing when you need scalable, automated route synchronization and can rely on BGP to exchange routes, as it avoids the administrative burden of manual path updates.
First verify that the pre-shared keys match on both ends, that the IKE versions are compatible, and that the IP addresses configured in the external VPN gateway resource exactly match the peer device's actual interfaces. Then examine Cloud Logging for IKE or IPsec authentication errors. For Classic VPN, also ensure firewall rules allow ESP protocol and UDP ports 500 and 4500.
Prepare and test your skills
Prepare and test your skills