This document describes recommended topologies and the corresponding availabilityService Level Agreement (SLA) for each HA VPN topology.For Classic VPN topologies, seeClassic VPN topologies.For more information about Cloud VPN, including both VPN types, see theCloud VPN overview.

For definitions of terms used on this page, seeKey terms.

Overview

HA VPN supports one of the following recommendedtopologies:

• Connect Google Cloud to your peer VPN gateway.This topology requires two VPN tunnels fromthe HA VPN gateway to achieve the high availability SLA.In this configuration, HA VPN has three typical peergateway configurations:

  • Two separate peer VPN gateways, each with its own IP address.
  • One peer VPN gateway with two separate IP addresses.
  • One peer VPN gateway with one IP address.

• Connect multiple Google Cloud VPCnetworks. To connect two Google CloudVPC networks, you create an HA VPNgateway in each network. The networks can be in the same or differentGoogle Cloud regions.

  You receive a different availability SLA for HA VPNgateways deployed in the same region versus those deployed across differentregions. For more information, seeHigh availability Configurations forHA VPN.

• Connect a HA VPN gateway to Compute Engine VMinstances. In this topology, you connect anHA VPN gateway to a Compute Engine virtual machine(VM) instance. Your VM instances can be in same zone or different zones.

  The availability SLA of the Compute Engine VM instance determinesthe availability SLA for the VPN connection.

• HA VPN over Cloud Interconnect.In this topology, you create HA VPN tunnels to carryIPsec-encrypted traffic over VLAN attachments of eitherDedicated Interconnect or Partner Interconnect. You canreserve regional internal IP address ranges for yourHA VPN gateways. Your peer VPN gateway can also haveinternal IP addresses. For more information and architecture diagrams, seeHA VPN over Cloud Interconnect deploymentarchitecture.

  In Google Cloud, all peer gateway scenarios are represented by a singleexternal peer VPN resource.

High availability configurations for HA VPN

The following table outlines the availability SLAs offered by differentHA VPN configurations:

Topology	Description	Availability SLA
Connect Google Cloud to your peer VPN gateway	Connect an HA VPN gateway to one or two separate peer VPN gateways	99.99%
Connect VPC networks by using HA VPN gateways	Connect two Google Cloud VPC networks by using an HA VPN gateway in each network. The HA VPN gateways are deployed in the same region. The VPC networks can be in the same region or different regions.	99.99%
HA VPN to Compute Engine VM instances in multiple zones	Connect an HA VPN gateway to Compute Engine VM instances with external IP addresses	99.9%
HA VPN to a single Compute Engine VM instance	Connect an HA VPN gateway to only one Compute Engine VM instance with an external IP address	The availability SLA is determined by the availability SLA provided for a single VM instance of memory-optimized machine family for Compute Engine. For more information, seeCompute Engine Service Level Agreement (SLA).

To help ensure the maximum availability SLA for your HA VPNconnections, we recommend that you configure two tunnels from yourHA VPN gateway to your peer VPN gateway or to anotherHA VPN gateway. Make sure that the peer VPN gateway is alsoconfigured to receive the same availability SLA.

To maintain connectivity in case of failure of one of the tunnels, connect allinterfaces of the HA VPN gateway to all interfaces ofthe peer gateway or another HA VPN gateway.

Connect Google Cloud to your peer VPN gateway

There are three typical peer gateway configurations forHA VPN:

• An HA VPN gateway to two separate peer VPN gateways, eachwith its own IP address
• An HA VPN gateway to one peer VPN gateway that uses twoseparate IP addresses
• An HA VPN gateway to one peer VPN gateway that uses oneIP address

To set up any of these configurations, seeCreate an HA VPN to a peer VPN gateway.

If you deploy an HA VPN gateway with IPV6_ONLYor IPV4_IPV6 stack type, then your VPN tunnels can support the exchange of IPv6traffic. IPv6 must also be enabled in the BGP sessions that you create for theVPN tunnels. In this scenario, you can assign IPv6 addresses to the on-premisessubnets and VPC subnets in the following topologies. For moreinformation, seeIPv6 support.

Connect two peer VPN gateways

If your peer-side gateway is hardware-based, having a second peer-sidegateway provides redundancy and failover on that side of the connection.A second physical gateway lets you take one of the gateways offline for softwareupgrades or other scheduled maintenance. It also protects you if there is afailure in one of the physical gateways.

In this topology, one HA VPN gateway connects to two peerVPN gateways. Each peer VPN gateway has one interface and one external IP address.The HA VPN gateway uses two tunnels, one tunnel to eachpeer VPN gateway.

In Google Cloud, theREDUNDANCY_TYPE for this configuration takes thevalueTWO_IPS_REDUNDANCY.

The following example provides 99.99% availability SLA.

Connect one peer VPN gateway with two IP addresses

This topology describes one HA VPN gateway that connectsto one peer VPN gateway that has two separate external IP addresses. TheHA VPN gateway uses two tunnels, one tunnel to eachexternal IP address on the peer VPN gateway.

In Google Cloud, theREDUNDANCY_TYPE for this configuration takesthe valueTWO_IPS_REDUNDANCY.

The following example provides 99.99% availability SLA.

Connect one peer VPN gateway with one IP address

This topology describes one HA VPN gateway that connectsto one peer VPN gateway that has one external IP address. The HA VPNgateway uses two tunnels, both tunnels to the single external IP address on thepeer VPN gateway.

In Google Cloud, theREDUNDANCY_TYPE for this configuration takes the valueSINGLE_IP_INTERNALLY_REDUNDANT.

The following example provides 99.99% availability SLA.

Configure for 99.99% availability SLA

To meet the 99.99% availability SLA on the Google Cloud side, there mustbe a tunnel from each of the two interfaces on the HA VPNgateway to the corresponding interfaces on the peer gateway.

If the peer gateway has two interfaces, then configuring two tunnels, one fromeach peer interface to each HA VPN gateway interface, meetsthe requirements for the 99.99% availability SLA. A full mesh configuration isnot required for 99.99% availability SLAon the Google Cloud side.In this case, a full mesh is defined as two tunnels from eachHA VPN interface to each of the two interfaces on thepeer gateway. To confirm if your VPN vendor recommends a full meshconfiguration, see the documentation for your peer (on-premises) VPNgateway or contact your VPN vendor.

In configurations with two peer interfaces, tunnels on each of the followinginterfaces on the HA VPN gateway match the correspondinginterfaces on the peer gateway or gateways:

• HA VPNinterface 0 to peerinterface 0
• HA VPNinterface 1 to peerinterface 1

Examples are shown in the diagrams fortwo peer VPN gateways, two interfacesandone peer VPN gateway, two interfaces.

If there is only one peer interface on one peer gateway, each tunnel from eachHA VPN gateway interface must connect to the singlepeer interface. See the diagram forone peer VPN gateway,one interface.

Caution: To receive the 99.99% availability SLA, configure at least one tunnelon each HA VPN gateway interface. Configuring only onetunnel from a single HA VPN interface to a single interfaceon the peer gateway doesn't provide enough redundancy to meet the availability SLAbecause there is an unused interface on the HA VPN gateway,which does not have a tunnel configured on it.

The following exampledoes not provide 99.99% availability SLA:

• HA VPNinterface 0 to peerinterface 0

Active-active and active-passive routing options for HA VPN

If a Cloud VPN tunnel goes down, it restarts automatically. If anentire virtual VPN device fails, Cloud VPN automatically instantiates anew one with the same configuration. The new gateway and tunnel connectautomatically.

VPN tunnels connected to HA VPN gateways must use dynamic(BGP) routing. Depending on the way that you configure route priorities forHA VPN tunnels, you can create an active-active oractive-passive routing configuration. For both of these routing configurations,both VPN tunnels remain active.

The following table compares the features of an active-active or active-passiverouting configuration.

Feature	Active-active	Active-passive
Throughput	The effective aggregate throughput is thecombined throughput of both tunnels.	After reducing from two active tunnels to one, theeffective overall throughput is cut in half, which can result in slower connectivity or dropped packets.
Route advertisement	Your peer gateway advertises the peer network's routes withidentical multi-exit discriminator (MED) values for each tunnel. The Cloud Router managing the Cloud VPN tunnels imports these routes as custom dynamic routes in yourVPC network withidentical priorities. Egress traffic sent to your peer network usesequal-cost multipath (ECMP) routing. The same Cloud Router usesidentical priorities to advertise routes to your VPC network. Your peer gatewayuses ECMP to use these routes to send egress traffic to Google Cloud.	Your peer gateway advertises the peer network's routes withdifferent MED values for each tunnel. The Cloud Router managing the Cloud VPN tunnels imports these routes as custom dynamic routes in yourVPC network withdifferent priorities. Egress traffic sent to your peer network usesthe route with the highest priority, as long as the associated tunnel is available. The same Cloud Router usesdifferent priorities for each tunnel to advertise routes to your VPC network. Your peer gateway can onlyuse the tunnel with highest priority to send traffic to Google Cloud.
Failover	If the tunnel becomes unhealthy—for example, because DPD is down, then Cloud Router withdraws the learned routes whose next hops are the unavailable tunnel. If a BGP session down occurs, Cloud Router removes the learned routes whose next hops are the unavailable tunnel, without causing a tunnel to be unhealthy. The withdrawal process can take40-60 seconds, during which packet loss is expected.	If the tunnel becomes unhealthy—for example, because DPD is down, then Cloud Router withdraws the learned routes whose next hops are the unavailable tunnel. If a BGP session down occurs, Cloud Router removes the learned routes whose next hops are the unavailable tunnel, without causing a tunnel to be unhealthy. The withdrawal process can take 40-60 seconds, during which packet loss is expected. Uses a maximum of one tunnel at a time so that the second tunnel is able to handle all your egress bandwidth if the first tunnel fails and needs to be failed over.

Active-passive routing in full mesh topologies

If Cloud Router receives the same prefix with different MED valuesthrough a given Cloud VPN interface, it only imports the route with thehighest priority to the VPC network. The other inactive routesare not visible in the Google Cloud console or through the Google Cloud CLI. If theroute with the highest priority becomes unavailable, Cloud Routerwithdraws it and automatically imports the next best route to theVPC network.

Using multiple tunnels or gateways

Note: For an example of a multiple-tunnel active-passive scenario, seeConfiguring HA VPN for morebandwidth.Caution: We recommend avoiding an active-passive configuration when you havemore than two HA VPN tunnels. If you use an active-passiveconfiguration across multiple HA VPNgateways—with an active and passive tunnel pair configured on eachgateway—HA VPN doesn't use the passive tunnels forfailover until all the active tunnels on all gateways have failed. Configuringmultiple gateways with an active-passive configurationcan cause bandwidthloss.

Depending on the peer gateway configuration, it's possible to construct routessuch that some traffic traverses one tunnel and other traffic traverses anothertunnel due to route priorities (MED values). Similarly, you can adjust the basepriority that the Cloud Router uses to share your VPCnetwork routes. These situations demonstrate possible routing configurationsthat are neither purely active-active nor purely active-passive.

Recommended routing option

When using a single HA VPN gateway, we recommend using anactive-passive routing configuration. With this configuration, the observedbandwidth capacity at the time of normal tunnel operation matches the bandwidthcapacity observed during failover. This type of configuration is easier tomanage because the observed bandwidth limit stays constant, except for themultiple gateway scenario described previously.

When using multiple HA VPN gateways, we recommend using anactive-active routing configuration. With this configuration, the observedbandwidth capacity at the time of normal tunnel operation is twice that of themaximum bandwidth capacity. However, this configuration effectively underprovisions the tunnels and can cause dropped traffic in case of failover.

Connect VPC networks by using HA VPN gateways

You can connect two Google Cloud VPC networks by usingan HA VPN gateway in each network. TheVPC networks and the HA VPN gatewayscan be in the same or different regions.

You can connect more than two VPC networks by using transitiverouting. To achieve transitive routing, create ahub VPCnetwork and connect your other VPC networks to this hub by usingindividual HA VPN connections.

The availability SLA in this topology on whether the HA VPNgateways are in the same region or different regions. You get a higheravailability SLA if the HA VPN gateways are in the sameregion.

Connect VPC networks

You can connect two VPC networks together by using anHA VPN gateway in each network.The HA VPN gateways must be deployed in the same region toget the best availability SLA even if the VPC networks are indifferent regions. Each HA VPN gatewayidentifies the other gateway by its name.

The following example provides 99.99% availability SLA.

To set up this configuration, seeCreate two fully configured HA VPN gateways that connect to each other.

Configure for 99.99% availability SLA

Caution: Both HA VPN gateways must be in the same regionto provide 99.99% availability SLA. Configuring only one tunnel on one interface foreach HA VPN gateway doesn't provide 99.99% availability SLA.

To help ensure 99.99% availability SLA, configure each HA VPNgateway with two tunnels so that both of the following are true:

• Tunnel 0 connectsinterface 0 on one HA VPN gatewaytointerface 0 on the other HA VPN gateway.
• Tunnel 1 connectsinterface 1 on one HA VPN gatewaytointerface 1 on the other HA VPN gateway.

You can connect two VPC networks together by using anHA VPN gateway in each network, where theHA VPN gateways are in different regions. However, thistopology provides a 99.9% availability SLA.

Unless you have a requirement for the HA VPN gatewaysto be in different regions, we don't recommend having theHA VPN gateways in different regions.VPC networks are global resources, which means you canuse HA VPN to connect resources in different regions whilethe HA VPN gateways are deployed in the same region.

The following example provides 99.9% availability SLA.

To set up this configuration, seeCreate two fully configured HA VPN gateways that connectto each other.

Configure for 99.9% availability SLA

To help ensure 99.9% availability SLA if the VPN gateways are in differentregions, configure each HA VPNgateway with two tunnels so that both of the following are true:

• Tunnel 0 connectsinterface 0 on one HA VPN gatewaytointerface 0 on the other HA VPN gateway.
• Tunnel 1 connectsinterface 1 on one HA VPN gatewaytointerface 1 on the other HA VPN gateway.

To receive a better availability SLA, deploy the HA VPNgateways in the same region . This configuration also lets you connectVPC networks in different regions.

Connect a HA VPN gateway to Compute Engine VM instances

With HA VPN, you can establish a secure connectionbetween an HA VPN gateway and Compute EngineVM instances that function as network virtual appliances withan IPsec implementation. This topology provides 99.9% availability SLA whenconfigured correctly.

Connect HA VPN gateway to multiple VM instances

In this topology, an HA VPN gateway connects to twoCompute Engine VM instances. The HA VPNgateway and the VMs are in two different Virtual Private Cloud networks. The two VMsare in different zones, with each VM having an external IP address. The VMinstances behave like peer VPN gateways.

This topology is especially useful when you want to connectHA VPN to a third-party network virtual appliance VMhosted in a Compute Engine VM instance. For example, by using this topology, you canupgrade one of the network virtual appliance VMswithout any downtime to the VPN connection.

In the diagram, the HA VPN gateway is in a VPCnetwork namednetwork-a, and the two VMs are innetwork-b. Both VPCnetworks are located inus-central1. The HA VPNgateway innetwork-a is configured with the external IP addresses of each ofthe VMs innetwork-b. You can also have the HA VPN gateway andthe VMs in two different regions.We recommend that you use this topology to improve availability.

The following example provides 99.9% availability SLA.

To set up this configuration, seeConnect HA VPN toCompute Engine VMs.

Configure for 99.9% availability SLA

To meet the 99.9% SLA, there must be at least two tunnels from each of the twointerfaces on the HA VPN gateway to the correspondinginterfaces on each of the VMs. We recommend that you use this topology to gethigher availability SLA.

Two tunnels on each of the following interfaces on theHA VPN gateway connect to the interfaces on the VM:

• Tunnel 0 frominterface 0 tous-central1-vm-a intheus-central1-a zone
• Tunnel 1 frominterface 1 tous-central1-vm-a intheus-central1-a zone
• Tunnel 2 frominterface 0 tous-central1-vm-b intheus-central1-b zone
• Tunnel 3 frominterface 1 tous-central1-vm-b intheus-central1-b zone

Connect HA VPN gateway HA VPN to a single VM instance

HA VPN lets you connect a HA VPN gateway to aCompute Engine virtual machine (VM) instance that works as anetwork virtual appliance and runs an IPsec VPN implementation. TheHA VPN gateway and the VM are in two different VPCs. The VM hasan external IP address.

Overall availability is determined by the availability SLA provided for a singleVM instance of memory-optimized machine family for Compute Engine.For more information, seeCompute Engine Service Level Agreement (SLA).

To set up this configuration, seeConnect HA VPN toCompute Engine VMs.

Configure for 99.9% availability SLA

To meet the 99.9% availability SLA, there must be two tunnels from each of thetwo interfaces on the HA VPN gateway to the interface ofthe Compute Engine VM.

Important: Overall availability is determined by the availability SLA providedfor a single VM instance of memory-optimized machine family forCompute Engine. For more information, seeCompute Engine Service Level Agreement (SLA).

Two tunnels on each of the following interfaces on theHA VPN gateway connect to the interfaces on VM:

• Tunnel 0 frominterface 0 tous-central1-vm-a intheus-central1-a zone
• Tunnel 1 frominterface 1 tous-central1-vm-a intheus-central1-a zone

What's next

• To use high-availability and high-throughput scenarios or multiplesubnet scenarios, seeAdvanced configurations.
• To help you solve common issues that you might encounter when usingCloud VPN, seeTroubleshooting.