HA VPN over Cloud Interconnect overview

HA VPN over Cloud Interconnect lets you encrypt the traffic that traverses yourDedicated Interconnect or Partner Interconnect connections. Touse HA VPN over Cloud Interconnect, you deployHA VPNtunnels over your VLAN attachments.

With HA VPN over Cloud Interconnect, you can improve the overall security ofyour business and maintain compliance with existing and upcoming industryregulations. For example, you might be required to encrypt the outgoing trafficfrom your applications or ensure that data is encrypted in transit over thirdparties.

You have many choices in meeting these requirements. Encryption can be performedat several layers in the OSI stack and at some layers might not be universallysupported. For example, Transport Layer Security (TLS) is not supported for allTCP-based protocols, and enabling Datagram TLS (DTLS) might not be supportedfor all UDP-based protocols. One solution is to implement encryption at thenetwork layer with the IPsec protocol.

As a solution, HA VPN over Cloud Interconnect has the advantage of providingdeployment tools by using the Google Cloud console, the Google Cloud CLI, and theCompute Engine API. You can also use internal IP addresses for yourHA VPN gateways. The VLAN attachments that you create forHA VPN over Cloud Interconnect supportconnections toPrivate Service Connectendpoints.Finally, HA VPN over Cloud Interconnect has an SLA that is derived from itsunderlying components, Cloud VPN and Cloud Interconnect. For moreinformation, seeSLA.

Another option is to create a self-managed (non-Google Cloud) VPN gateway inyour Virtual Private Cloud (VPC) network and assign an internal IP address toeach gateway. For example, you can run a strongSwan VPN on a Compute Engineinstance. You then terminate IPsec tunnels to those VPN gateways by usingCloud Interconnect from an on-premises environment. For moreinformation about HA VPN options, seeHA VPNtopologies.

You cannot deploy Classic VPN gateways and tunnels overCloud Interconnect.

Deployment architecture

When you deploy HA VPN over Cloud Interconnect, you create two operational tiers:

  • The Cloud Interconnect tier, which includes the VLAN attachments and the Cloud Router for Cloud Interconnect.
  • The HA VPN tier, which includes the HA VPN gateways and tunnels and the Cloud Router for HA VPN.

Each tier requires its own Cloud Router:

  • The Cloud Router for Cloud Interconnect is used exclusively to exchange VPN gateway prefixes between the VLAN attachments. This Cloud Router is used only by the VLAN attachments of the Cloud Interconnect tier. It cannot be used in the HA VPN tier.
  • The Cloud Router for HA VPN exchanges prefixes between your VPC network and your on-premises network. You configure the Cloud Router for HA VPN and its BGP sessions in the same way you would for a regular HA VPN deployment.

You build the HA VPN tier on top of the Cloud Interconnect tier. Therefore, the HA VPN tier requires that the Cloud Interconnect tier, based on either Dedicated Interconnect or Partner Interconnect, is properly configured and operational.

The following diagram depicts an HA VPN over Cloud Interconnect deployment.

Deployment architecture for HA VPN overCloud Interconnect (click to enlarge).
Figure 1. Deployment architecture for HA VPN over Cloud Interconnect (click to enlarge).

The IP address ranges learned by the Cloud Router on theCloud Interconnect tier are used to select theinternal traffic sent to the HA VPN gateways and the VLAN attachments.

Failover

The following sections describe different types ofHA VPN over Cloud Interconnect failover.

Cloud Interconnect failover

When the BGP session on the Cloud Interconnect tier goes down,the corresponding HA VPN to Cloud Interconnect routesare retracted. This retraction leads to HA VPN tunnel interruption.As a result, routes are shifted to the other HA VPN tunnelsthat are hosted on the other VLAN attachment.

The following diagram depicts Cloud Interconnect failover.

Cloud Interconnect VLAN attachment failover for HA VPN over Cloud Interconnect (click to enlarge).
Figure 2. Cloud Interconnect VLAN attachment failover for HA VPN over Cloud Interconnect (click to enlarge).

HA VPN tunnel failover

When a BGP session on the HA VPN tier goes down,normal BGP failover occurs, and HA VPN tunnel trafficis routed to other available HA VPN tunnels.The BGP sessions of the Cloud Interconnect tier are unaffected.

The following diagram depicts HA VPN tunnel failover.

HA VPN tunnel failover for HA VPN over Cloud Interconnect (click to enlarge).
Figure 3. HA VPN tunnel failover for HA VPN over Cloud Interconnect (click to enlarge).

SLA

HA VPNis a high-availability (HA) Cloud VPN solution that lets you securely connectyour on-premises network to your VPC network by using an IPsecVPN connection in a singleGoogle Cloud region.HA VPN, deployed on its own, has its ownSLA when properlyconfigured.

However, because HA VPN is deployed on top ofCloud Interconnect, the overall SLA forHA VPN over Cloud Interconnect matches the SLA of theCloud Interconnect topology that you choose to deploy.

The SLA for HA VPN over Cloud Interconnect depends on theCloud Interconnect topology that you choose to deploy. To qualify foran SLA, your deployments must have a gateway with 2 VLAN attachments associated(failover).

Pricing summary

For HA VPN over Cloud Interconnect deployments, you are charged for thefollowing components:

  • Your Dedicated Interconnect connection, if you use Dedicated Interconnect.
  • Each VLAN attachment.
  • Each VPN tunnel.
  • Cloud Interconnect egress traffic only. You are not charged for the Cloud VPN egress traffic carried by your HA VPN tunnels.
  • Regional external IP addresses assigned to your HA VPN gateways, if you choose to use external IP addresses. However, you are only charged for the IP addresses that are not in use by VPN tunnels.

For more information,seeCloud VPN Pricing andCloud Interconnect Pricing.

Limitations

  • Configuration:

    • The HA VPN gateway is an immutable resource. Onceyou create and associate a VLAN attachment, you cannot change theassociations between the attachment and the interfaces of theHA VPN gateway.

      For example, if you decide later that you need to configure forfailover, you must create a newHA VPN gateway and then delete the originalgateway and its tunnels.

    • You must select IPsec encryption when you create the VLAN attachment.You cannot add encryption to an existing attachment at a later time.

    • For each VLAN attachment, you can reserve only one internal IP addressrange for your HA VPN gateway interfaces.

    • EnablingBidirectional Forwarding Detection (BFD)does not provide faster failure detection forHA VPN over Cloud Interconnect deployments.

    • HA VPN over Cloud Interconnect supports IPv4 and IPv6 (dual-stack)HA VPN gateways. To create dual-stackHA VPN gateways, you must use the Google Cloud CLIor Cloud Interconnect API. You cannot use the HA VPN over Cloud Interconnectdeployment wizard in the Google Cloud console.

  • Payload and latency:

    • HA VPN over Cloud Interconnect differentiates between the followingmaximum transmission unit (MTU) values:

    • Each HA VPN tunnel can support up to 250,000 packets per secondfor the sum of ingress and egress traffic. This is a limitation ofHA VPN. For more information, seeLimits in theCloud VPN documentation.

    • For a single VLAN attachment with encryption enabled, the combinedinbound and outbound throughput is limited to 50 Gbps.

    • In terms of latency, adding IPsec encryption to Cloud Interconnect

      traffic adds some delay. During normal operations, the added latency isunder 5 milliseconds.

  • You can terminate the VLAN attachments and IPsec tunnels on two differentphysical on-premises devices. The BGP sessions over each VLAN attachment,advertising and negotiating the VPN gateway prefixes, should terminate onthe on-premises VLAN attachment device. The BGP sessions over each VPNtunnel, advertising the cloud prefixes (as usual), should terminate on theVPN device.

  • The ASNs of the two Cloud Routers can be different.Cloud Router interfaces that peer with on-premises devices cannotbe assigned RFC 1918 (private) IP addresses.

What's next?

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.