Cloud VPN overview

This page describes concepts related to Cloud VPN. For definitions of terms used in the Cloud VPN documentation, see Key terms.

Cloud VPN securely extends your peer network to your Virtual Private Cloud (VPC) network through an IPsec VPN connection. The VPN connection encrypts traffic traveling between the networks, with one VPN gateway handling encryption and the other handling decryption. This process protects your data during transmission. You can also connect two VPC networks together by connecting two Cloud VPN instances. You cannot use Cloud VPN to route traffic to the public internet; it is designed for secure communication between private networks.

Choose a hybrid networking solution

To determine whether to use Cloud VPN, Dedicated Interconnect, Partner Interconnect, or Cloud Router as your hybrid networking connection to Google Cloud, see Choosing a Network Connectivity product.

Try it for yourself

If you're new to Google Cloud, create an account to evaluate how Cloud VPN performs in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Try Cloud VPN free

To enhance the security of your Dedicated Interconnect or Partner Interconnect connection, use HA VPN over Cloud Interconnect. This solution establishes encrypted HA VPN tunnels over your VLAN attachments.

Types of Cloud VPN

Google Cloud offers two types of Cloud VPN gateways:

HA VPN

HA VPN is a high-availability (HA) Cloud VPN solution that lets you securely connect your on-premises network to your VPC network through an IPsec VPN connection. Based on the topology and configuration, HA VPN can provide an SLA of 99.99% or 99.9% service availability.

When you create an HA VPN gateway, Google Cloud automatically chooses two external IP addresses, one for each of its interfaces. Each IP address is automatically chosen from a unique address pool to support high availability. Each of the HA VPN gateway interfaces supports multiple tunnels. You can also create multiple HA VPN gateways. When you delete the HA VPN gateway, Google Cloud releases the IP addresses for reuse. You can configure an HA VPN gateway with only one active interface and one external IP address; however, this configuration does not provide an availability SLA.

One option for using HA VPN is to use HA VPN over Cloud Interconnect. With HA VPN over Cloud Interconnect, you get the security of IPsec encryption from Cloud VPN alongside the increased capacity of Cloud Interconnect. In addition, because you are using Cloud Interconnect, your network traffic never traverses the public internet. If you use Partner Interconnect, you must add IPsec encryption to your Cloud Interconnect traffic to meet data security and compliance requirements when connecting to third-party providers. HA VPN uses an external VPN gateway resource in Google Cloud to provide information to Google Cloud about your peer VPN gateway or gateways.

In the API documentation and in gcloud commands, HA VPN gateways are referred to as VPN gateways rather than target VPN gateways. You don't need to create any forwarding rules for HA VPN gateways.

HA VPN can provide an availability SLA of 99.99% or 99.9% depending on the topologies or configuration scenarios. For more information about HA VPN topologies and supported SLAs, see HA VPN topologies.

While setting up HA VPN, consider the following guidelines:

  • When you connect an HA VPN gateway to another HA VPN gateway, the gateways must use identical IP stack types. For example, if you create an HA VPN gateway with the stack type of IPV4_IPV6, the other HA VPN gateway must also be set to IPV4_IPV6.

  • Configure two VPN tunnels from the perspective of the Cloud VPN gateway:

    • If you have two peer VPN gateway devices, each of the tunnels from each interface on the Cloud VPN gateway must be connected to its own peer gateway.
    • If you have a single peer VPN gateway device with two interfaces, each of the tunnels from each interface on the Cloud VPN gateway must be connected to its own interface on the peer gateway.
    • If you have a single peer VPN gateway device with a single interface, both of the tunnels from each interface on the Cloud VPN gateway must be connected to the same interface on the peer gateway.

  • A peer VPN device must be configured with adequate redundancy. The device vendor specifies the details of an adequately redundant configuration, which might include multiple hardware instances. For details, see the vendor documentation for the peer VPN device.

    If two peer devices are required, each peer device must be connected to a different HA VPN gateway interface. If the peer side is another cloud provider like AWS, VPN connections must be configured with adequate redundancy on the AWS side as well.

  • Your peer VPN gateway device must support dynamic Border Gateway Protocol (BGP) routing.

    The following diagram shows the HA VPN concept, showing a topology that includes the two interfaces of an HA VPN gateway connected to two peer VPN gateways. For more detailed HA VPN topologies (configuration scenarios), see HA VPN topologies.

    An HA VPN gateway to two peer VPN gateways.
    An HA VPN gateway to two peer VPN gateways (click to enlarge).

Classic VPN

All Cloud VPN gateways created before the introduction of HA VPN are considered Classic VPN gateways. For information about how to move from Classic VPN to HA VPN, see Move from Classic VPN to HA VPN.

In contrast to HA VPN, Classic VPN gateways have a single interface, a single external IP address, and support tunnels that use static routing (policy based or route based). You can also configure dynamic routing (BGP) for Classic VPN, but only for tunnels that connect to third-party VPN gateway software running on Google Cloud VM instances.

Classic VPN gateways provide an SLA of 99.9% service availability.

Classic VPN gateways don't support IPv6.

For supported Classic VPN topologies, see the Classic VPN topologies page.

Classic VPNs are referred to as target VPN gateways in the API documentation and in the Google Cloud CLI.

Comparison table

The following table compares HA VPN features with Classic VPN features.

Feature HA VPN Classic VPN
SLA Provides 99.99% SLA for most topologies, with a few exceptions. For more information, see HA VPN topologies. Provides a 99.9% SLA.
Creation of external IP addresses and forwarding rules External IP addresses created from a pool; no forwarding rules required. External IP addresses and forwarding rules must be created.
Supported routing options Only dynamic routing (BGP). Static routing (policy-based, route-based). Dynamic routing is only supported for tunnels that connect to third-party VPN gateway software running on Google Cloud VM instances.
Two tunnels from one Cloud VPN gateway to the same peer gateway Supported Not supported
Connect a Cloud VPN gateway to Compute Engine VMs with external IP addresses. Supported and recommended topology. For more information, see HA VPN topologies. Supported.
API resources Known as the vpn-gateway resource. Known as the target-vpn-gateway resource.
IPv6 traffic Supports dual stack (IPv4 and IPv6) and IPv6-only configuration Not supported

Specifications

Cloud VPN has the following specifications:

  • Cloud VPN only supports site-to-site IPsec VPN connectivity, subject to the requirements listed in this section. It does not support client-to-gateway scenarios. In other words, Cloud VPN doesn't support use cases where client computers need to "dial in" to a VPN by using client VPN software.

    Cloud VPN only supports IPsec. Other VPN technologies (such as SSL VPN) are not supported.

  • Cloud VPN can be used with VPC networks and legacy networks. For VPC networks, we recommend custom mode VPC networks so that you have full control over the ranges of IP addresses used by the subnets in the network.

    • Classic VPN and HA VPN gateways use external (internet routable) IPv4 addresses. Only ESP, UDP 500, and UDP 4500 traffic is permitted to these addresses. This applies to Cloud VPN addresses configured by you for Classic VPN or to automatically assigned IP addresses for HA VPN.

    • If IP address ranges for on-premises subnets overlap with IP addresses used by subnets in your VPC network, to determine how routing conflicts are resolved, see Order of routes.

  • The following Cloud VPN traffic remains within Google's production network:

    • Between two HA VPN gateways
    • Between two Classic VPN gateways
    • Between a Classic VPN or HA VPN gateway and the external IP address of a Compute Engine VM acting as a VPN gateway

  • Cloud VPN can be used with Private Google Access for on-premises hosts. For more information, see Private access options for services.

  • Each Cloud VPN gateway must be connected to another Cloud VPN gateway or a peer VPN gateway.

  • The peer VPN gateway must have a static external (internet routable) IPv4 address. You need this IP address to configure Cloud VPN.

    • If your peer VPN gateway is behind a firewall rule, you must configure the firewall rule to pass ESP (IPsec) protocol and IKE (UDP 500 and UDP 4500) traffic to it. If the firewall rule provides network address translation (NAT), see UDP encapsulation and NAT-T.

  • Cloud VPN requires that the peer VPN gateway be configured to support prefragmentation. Packets must be fragmented before being encapsulated.

  • Cloud VPN uses replay detection with a window of 4096 packets. You cannot turn this off.

  • Cloud VPN supports generic routing encapsulation (GRE) traffic. Support for GRE lets you terminate GRE traffic on a VM from the internet (external IP address) and Cloud VPN or Cloud Interconnect (internal IP address). The decapsulated traffic can then be forwarded to a reachable destination. GRE lets you use services such as Secure Access Service Edge (SASE) and SD-WAN. You must create a firewall rule to allow GRE traffic.

  • HA VPN tunnels support the exchange of IPv6 traffic, but Classic VPN tunnels don't.

Network bandwidth

Each Cloud VPN tunnel supports up to 250,000 packets per second for the sum of ingress and egress traffic. Depending on average packet size in the tunnel, 250,000 packets per second is equivalent to between 1 Gbps and 3 Gbps of bandwidth.

The metrics related to this limit are Sent bytes and Received bytes, which are described in View logs and metrics. Consider that the unit for the metrics is bytes, while the 3-Gbps limit refers to bits per second. When converted to bytes, the limit is 375 megabytes per second (MBps). When measuring usage against the limit, use the sum of Sent bytes and Received bytes compared to the converted limit of 375 MBps.

For information about how to create alerting policies, see Define alerts for VPN tunnel bandwidth.

Factors that affect bandwidth

The bandwidth is influenced by a number of factors, including the following:

  • The network connection between the Cloud VPN gateway and your peer gateway:

    • Network bandwidth between the two gateways. If you have established a Direct Peering relationship with Google, throughput is higher than if your VPN traffic is sent over the public internet.

    • Round-trip time (RTT) and packet loss. Elevated RTT or packet loss rates greatly reduce TCP performance.

  • Capabilities of your peer VPN gateway. For more information, see your device's documentation.

  • Packet size. Cloud VPN uses the IPsec protocol in tunnel mode, encapsulating and encrypting entire IP packets in Encapsulating Security Payload (ESP), and then storing the ESP data in a second, outer IP packet. Consequently, there is both a gateway MTU for the IPsec encapsulated packets and a payload MTU for packets before and after IPsec encapsulation. For details, see MTU considerations.

  • Packet rate. For ingress and egress, the recommended maximum packet rate for each Cloud VPN tunnel is 250,000 packets per second (pps). If you need to send packets at a higher rate, you must create more VPN tunnels.

When measuring TCP bandwidth of a VPN tunnel, you should measure more than one simultaneous TCP stream. If you are using the iperf tool, use the -P parameter to specify the number of simultaneous streams.

IPv6 support

Cloud VPN supports IPv6 in HA VPN, but not in Classic VPN.

To support IPv6 traffic in HA VPN tunnels, do the following:

  • Use the IPV6_ONLY or IPV4_IPV6 stack type when creating a HA VPN gateway and tunnels that connect IPv6-enabled VPC networks with other IPv6-enabled networks. These networks can be on-premises networks, multicloud networks, or other VPC networks.

  • Include dual-stack subnets or IPv6-only subnets in your IPv6-enabled VPC networks. Additionally, assign internal IPv6 ranges to the subnets.

The following table summarizes the external IP addresses allowed for each stack type of the HA VPN gateway.

Stack type Supported gateway external IP addresses
IPV4_ONLY IPv4
IPV4_IPV6 IPv4, IPv6
IPV6_ONLY IPv6

Organization policy constraints for IPv6

You can disable the creation of all IPv6 hybrid resources in your project by setting the following organization policy to true:

  • constraints/compute.disableHybridCloudIpv6

For HA VPN, this organization policy constraint prevents the creation of any dual-stack HA VPN gateways and IPv6-only HA VPN gateways in the project. This policy also prevents the creation of IPv6 BGP sessions and dual-stack Dedicated Interconnect VLAN attachments.

Stack types and BGP sessions

HA VPN gateways support different stack types. The stack type of an HA VPN gateway determines what version of IP traffic is allowed in your HA VPN tunnels.

When you create the HA VPN tunnels for a dual-stack HA VPN gateway, you can create either an IPv6 BGP session for IPv6 route exchange, or an IPv4 BGP session that exchanges IPv6 routes by using multiprotocol BGP (MP-BGP).

The following table summarizes the types of BGP sessions supported for each stack type.

Stack type Supported BGP sessions Gateway external IP addresses
Single stack (IPv4 only) IPv4 BGP, no MP-BGP IPv4
Single stack (IPv6 only) IPv6 BGP, no MP-BGP IPv6
Dual stack (IPv4 and IPv6)
  • IPv4 BGP, with or without MP-BGP
  • IPv6 BGP, with or without MP-BGP
  • Both IPv4 BGP and IPv6 BGP, no MP-BGP
 IPv4 and IPv6

For more information about BGP sessions, see Establish BGP sessions in the Cloud Router documentation.

Single-stack IPv4-only gateways

By default, an HA VPN gateway is assigned the IPv4-only stack type and is automatically assigned two external IPv4 addresses.

An IPv4-only HA VPN gateway can support only IPv4 traffic.

Use the following procedures to create IPv4-only HA VPN gateways and IPv4 BGP sessions.

Single-stack IPv6-only gateways

An IPv6-only HA VPN gateway supports only IPv6 traffic. By default, an IPv6-only HA VPN gateway is assigned two external IPv6 addresses.

Use the following procedures to create IPv6-only HA VPN gateways and IPv6 BGP sessions.

Dual-stack IPv4 and IPv6 gateways

An HA VPN gateway that is configured with the dual-stack (IPv4 and IPv6) stack type can support both IPv4 and IPv6 traffic.

For a dual-stack HA VPN gateway, you can configure your Cloud Router with an IPv4 BGP session, an IPv6 BGP session, or both. If you configure only one BGP session, you can enable MP-BGP to allow that session to exchange both IPv4 and IPv6 routes. If you create an IPv4 BGP session and an IPv6 BGP session, you can't enable MP-BGP on either session.

To exchange IPv6 routes on an IPv4 BGP session using MP-BGP, you must configure that session with IPv6 next hop addresses. Similarly, to exchange IPv4 routes on an IPv6 BGP session using MP-BGP, you must configure that session with IPv4 next hop addresses. You can configure these next hop addresses either manually or automatically.

If you manually configure the next hop addresses, you must select them from the Google-owned IPv6 Global Unicast Address (GUA) range 2600:2d00:0:2::/63, or from the IPv4 link-local address range 169.254.0.0./16. These IP address ranges are pre-allocated by Google. The next hop IP addresses you select must be unique across all Cloud Routers within your VPC network.

If you select automatic configuration, Google Cloud selects the next hop IP addresses for you.

Use the following procedures to create dual-stack HA VPN gateways and all supported BGP sessions.

IPsec and IKE support

Cloud VPN supports IKEv1 and IKEv2 by using an IKE pre-shared key (shared secret) and IKE ciphers. Cloud VPN only supports a pre-shared key for authentication. When you create the Cloud VPN tunnel, specify a pre-shared key. When you create the tunnel at the peer gateway, specify this same pre-shared key.

Cloud VPN supports ESP in tunnel mode with authentication, but does not support AH or ESP in transport mode .

You must use IKEv2 to enable IPv6 traffic in HA VPN.

Cloud VPN does not perform policy-related filtering on incoming authentication packets. Outgoing packets are filtered based on the IP range configured on the Cloud VPN gateway.

For guidelines for creating a strong pre-shared key, see Generate a strong pre-shared key. For ciphers and configuration parameters supported by Cloud VPN, see Supported IKE ciphers.

IKE and dead peer detection

Cloud VPN supports dead peer detection (DPD), per the DPD Protocol section of RFC 3706.

To verify that the peer is alive, Cloud VPN might send DPD packets at any time, per RFC 3706. If the DPD requests aren't returned after several retries, Cloud VPN recognizes that the VPN tunnel is unhealthy. The unhealthy VPN tunnel in turn causes removal of the routes using this tunnel as a next-hop (BGP routes or static routes) triggering a failover of VM traffic to other VPN tunnels that are healthy.

The DPD interval isn't configurable in Cloud VPN.

UDP encapsulation and NAT-T

For information about how to configure your peer device to support NAT-Traversal (NAT-T) with Cloud VPN, see UDP encapsulation in the Advanced overview.

Cloud VPN as a data transfer network

Before you use Cloud VPN, carefully review Section 2 of the General Service Terms for Google Cloud.

Using Network Connectivity Center, you can use HA VPN tunnels to connect on-premises networks together, passing traffic between them as a data transfer network. You connect the networks by attaching a pair of tunnels to a Network Connectivity Center spoke for each on-premises location. You then connect each spoke to a Network Connectivity Center hub.

For more information about Network Connectivity Center, see the Network Connectivity Center overview.

Bring your own IP (BYOIP) support

For information about using BYOIP addresses with Cloud VPN, see Support for BYOIP addresses.

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

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

VPN tunnels connected to HA VPN gateways must use dynamic (BGP) routing. Depending on the way that you configure route priorities for HA VPN tunnels, you can create an active-active or active-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-passive routing configuration.

Feature Active-active Active-passive
Throughput The effective aggregate throughput is the combined throughput of both tunnels. After reducing from two active tunnels to one, the effective 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 with identical multi-exit discriminator (MED) values for each tunnel.

The Cloud Router managing the Cloud VPN tunnels imports these routes as custom dynamic routes in your VPC network with identical priorities.

Egress traffic sent to your peer network uses equal-cost multipath (ECMP) routing.

The same Cloud Router uses identical priorities to advertise routes to your VPC network.

Your peer gateway uses ECMP to use these routes to send egress traffic to Google Cloud.

Your peer gateway advertises the peer network's routes with different MED values for each tunnel.

The Cloud Router managing the Cloud VPN tunnels imports these routes as custom dynamic routes in your VPC network with different priorities.

Egress traffic sent to your peer network uses the route with the highest priority, as long as the associated tunnel is available.

The same Cloud Router uses different priorities for each tunnel to advertise routes to your VPC network.

Your peer gateway can only use 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 take 40-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 values through a given Cloud VPN interface, it only imports the route with the highest priority to the VPC network. The other inactive routes are not visible in the Google Cloud console or through the Google Cloud CLI. If the route with the highest priority becomes unavailable, Cloud Router withdraws it and automatically imports the next best route to the VPC network.

Using multiple tunnels or gateways

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

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

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

Restricting peer IP addresses through a Cloud VPN tunnel

If you're an Organization Policy Administrator (roles/orgpolicy.policyAdmin), you can create a policy constraint that restricts the IP addresses that users can specify for peer VPN gateways.

The restriction applies to all Cloud VPN tunnels—both Classic VPN and HA VPN—in a specific project, folder, or organization.

For steps describing how to restrict IP addresses, see Restrict IP addresses for peer VPN gateways.

Visualizing and monitoring Cloud VPN connections

Network Topology is a visualization tool that shows the topology of your VPC networks, hybrid connectivity to and from your on-premises networks, and the associated metrics. You can view your Cloud VPN gateways and VPN tunnels as entities in the Network Topology view.

A base entity is the lowest level of a particular hierarchy and represents a resource that can directly communicate with other resources over a network. Network Topology aggregates base entities into hierarchical entities that you can expand or collapse. When you first view a Network Topology graph, it aggregates all the base entities into their top-level hierarchy.

For example, Network Topology aggregates VPN tunnels into their VPN gateway connection. You can view the hierarchy by expanding or collapsing the VPN gateway icons.

For more information, see the Network Topology overview.

Maintenance and availability

Cloud VPN undergoes periodic maintenance. During maintenance, Cloud VPN tunnels are taken offline, resulting in brief drops in network traffic. When maintenance completes, Cloud VPN tunnels are automatically re-established.

Maintenance for Cloud VPN is a normal operational task that can happen at any time without prior notice. Maintenance periods are designed to be short enough so that the Cloud VPN SLA is not impacted.

HA VPN is the recommended method of configuring high-availability VPNs. For configuration options, see the HA VPN topologies page. If you are using Classic VPN for redundancy and high-throughput options, see the Classic VPN topologies page.

Best practices

To build your Cloud VPN effectively, use these best practices.

What's next