Cloud VPN overview

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

Cloud VPN securely connects your peer network to your Virtual Private Cloud (VPC) network through an IPsec VPN connection. Traffic traveling between the two networks is encrypted by one VPN gateway and then decrypted by the other VPN gateway. This action protects your data as it travels over the internet. You can also connect two instances of Cloud VPN to each other.

Choosing 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

Types of Cloud VPN

Google Cloud offers two types of Cloud VPN gateways: HA VPN and Classic VPN. However, Classic VPN is deprecating certain functionality on October 31, 2021. For more information, see the Classic VPN partial deprecation page.

For information about moving to HA VPN, see Moving to HA VPN from Classic 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 in a single region. HA VPN provides an SLA of 99.99% service availability.

When you create an HA VPN gateway, Google Cloud automatically chooses two external IP addresses, one for each of its fixed number of two 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 a 99.99% service availability SLA.

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 uses an external VPN gateway resource in Google Cloud to provide information to Google Cloud about your peer VPN gateway or gateways.

HA VPN requirements

Your Cloud VPN configuration must meet the following requirements to achieve a service-level availability of 99.99% for HA VPN:

  • When you connect an HA VPN gateway to your peer gateway, 99.99% availability is guaranteed only on the Google Cloud side of the connection. End-to-end availability is subject to proper configuration of the peer VPN gateway.

  • If both sides are Google Cloud gateways and are properly configured, end-to-end 99.99% availability is guaranteed.

  • To achieve high availability when both VPN gateways are located in VPC networks, you must use two HA VPN gateways, and both of them must be located in the same region.

    Even though both gateways must be located in the same region, if your VPC network uses global dynamic routing mode, the routes to the subnets that the gateways share with each other can be located in any region. If your VPC network uses regional dynamic routing mode, only routes to subnets in the same region are shared with the peer network. Learned routes are applied only to subnets in the same region as the VPN tunnel.

    For more information, see Dynamic routing mode.

  • HA VPN rejects Google Cloud IP addresses when they are configured in an external VPN gateway resource—for example, using the external IP address of a VM instance as the external IP address for the external VPN gateway resource. The only supported HA VPN topology between Google Cloud networks is where HA VPN is used on both sides, as documented in Creating an HA VPN between Google Cloud networks.

  • 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 (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 Cloud 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

In contrast, Classic VPN gateways have a single interface, a single external IP address, and support tunnels that use dynamic (BGP) or static routing (policy-based or route-based). They provide an SLA of 99.9% service availability.

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 gcloud command-line tool.

Comparison table

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

Feature HA VPN Classic VPN
SLA Provides a 99.99% SLA when configured with two interfaces and two external IP addresses. 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) or dynamic routing using BGP.
Two tunnels from one Cloud VPN gateway to the same peer gateway Supported Not supported
API resources Known as the vpn-gateway resource. Known as the target-vpn-gateway resource.


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 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 GRE traffic. Support for GRE allows you to 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 enables you to use services such as Secure Access Service Edge (SASE) and SD-WAN. You must create a firewall rule to allow GRE traffic.

Network bandwidth

Each Cloud VPN tunnel can support up to 3 gigabits per second (Gbps) for the sum of ingress and egress traffic.

The metrics related to this limit are Sent bytes and Received bytes, which are described in Monitoring metrics for Cloud VPN. 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 Defining alerts for VPN tunnel bandwidth.

For information about using the VPN tunnel utilization recommender, see Checking for VPN tunnel overutilization.

Factors that affect bandwidth

Actual bandwidth depends on several factors:

  • 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 a maximum transmission unit (MTU) of 1460 bytes. Peer VPN gateways must be configured to use an MTU of no greater than 1460 bytes. Because processing happens on a per-packet basis, for a given packet rate, a significant number of smaller packets can reduce overall throughput. To account for ESP overhead, you might also need to set the MTU values for systems sending traffic through VPN tunnels to values less than the MTU of the tunnel. For a detailed discussion and recommendations, 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.

Tunnel MTU

Cloud VPN always uses an MTU of 1460 bytes. If the VMs and networks on either side of the tunnel have higher MTUs, then Cloud VPN uses MSS clamping to reduce the TCP MTU setting to 1460. The VPN gateways can also use ICMP error messages to enable path MTU discovery (PMTUD), thus setting a lower MTU for UDP packets.

If UDP packets are being dropped, you can reduce the MTU of the specific VMs that are communicating across the tunnel. For Windows VMs and user-supplied images, setting the MTU lower is sufficient. For Google-provided Linux images, you also have to disable DHCP MTU updates for those VMs.

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.

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 Generating a strong pre-shared key. For ciphers and configuration parameters supported by Cloud VPN, see Supported IKE ciphers.

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.

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 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.


If one tunnel becomes unavailable, Cloud Router withdraws the learned custom dynamic routes whose next hops are the unavailable tunnel. This withdrawal process can take up to 40 seconds, during which packet loss is expected.

If one tunnel becomes unavailable, Cloud Router withdraws the learned custom dynamic routes whose next hops are the unavailable tunnel. This withdrawal process can take up to 40 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 gcloud command-line tool. 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 guaranteed bandwidth capacity. However, this configuration effectively underprovisions 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, you can create an organization policy constraint to define a set of peer IP addresses that a user is permitted to specify when creating new Cloud VPN tunnels in a specific project, folder, or organization.

The peer gateway IP addresses can be the IP addresses of either on-premises gateways or other Cloud VPN gateways.

To control the list of peer IP addresses that users can specify when creating new Cloud VPN tunnels, use the Resource Manager constraint constraints/compute.restrictVpnPeerIPs.

In the following example, an Organization Policy Administrator creates an organization policy constraint that defines the allowed peer VPN gateway IP address. This constraint has an allowList consisting of only IP address

Network Administrators in the project that contains the network-a VPC network can only create new Cloud VPN tunnels that connect to the peer gateway IP address The constraint disallows creation of any new Cloud VPN tunnels to a different peer gateway IP address.

Organization policy to restrict VPN peers.
Organization policy to restrict VPN peers (click to enlarge)

For steps describing how to restrict IP addresses, see the following:


  • The organizational policy constraint that restricts peer gateway IP addresses applies only to new Cloud VPN tunnels. The constraint forbids Cloud VPN tunnels created after the constraint is applied. For more information, see Understanding the Resource Manager hierarchy.

  • You can apply this constraint to Classic VPN tunnels that use static routing or dynamic routing with BGP or to HA VPN tunnels.

  • You can specify multiple allowedList or deniedList entries in a given policy, but you cannot use both of them at the same time.

  • You, or a Network Administrator with the correct permissions, must manage and maintain the lifecycle and integrity of your VPN tunnels.

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

  • To use high-availability and high-throughput scenarios or multiple subnet scenarios, see Advanced configurations.

  • To help you solve common issues that you might encounter when using Cloud VPN, see Troubleshooting.