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. Simultaneosely, 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 tunnels Maximum Transmission Unit (MTU) aligns with the VPC networks MTU setting. The troubleshoot flow starts at the tunnel state, moves to BGP session details, and then examines the specific error logs for each component.
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. If you use only one interface and tunnel, no SLA applies.
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.
Prepare and test your skills
Prepare and test your skills