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.
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 freeIf you want IPsec encryption and a connection that does not traverse the public internet, you can deploy HA VPN over Cloud Interconnect.
Types of Cloud VPN
Google Cloud offers two types of Cloud VPN gateways: HA VPN and Classic VPN. However, some Classic VPN features are deprecated. For more information, see Classic VPN dynamic routing partial deprecation.
For information about moving to HA VPN, see Move to HA VPN.
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 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 IPv4 addresses, one for each of its fixed number of two interfaces. Each IPv4 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.
One option for using HA VPN is to deploy HA VPN over Cloud Interconnect. HA VPN over Cloud Interconnect provides the benefit of IPsec encryption that you get from Cloud VPN while also deploying the larger capacity of Cloud Interconnect. In addition, because you are using Cloud Interconnect, your network traffic is never required to travel the public internet. Adding IPsec encryption to your Cloud Interconnect traffic is important for meeting your data encryption and other compliance needs, especially if you must connect to a third-party service provider, which is a requirement of Partner Interconnect.
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 correct configuration of the peer VPN gateway.
If both sides are Google Cloud gateways and are correctly 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.
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 toIPV4_IPV6.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 Create 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.
Classic VPN
All Cloud VPN gateways created before the introduction of HA VPN are considered Classic VPN gateways. To move from Classic VPN to HA VPN, see the detailed instructions.
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 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). 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 |
| API resources | Known as the vpn-gateway resource. |
Known as the target-vpn-gateway resource. |
| IPv6 traffic | Supported (dual stack IPv4 and IPv6 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 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.
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.
For information about using the VPN tunnel utilization recommender, see Check 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.
IPv6 support
Cloud VPN supports IPv6 in HA VPN, but not in Classic VPN.
You can create HA VPN gateways 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. To transport IPv6 traffic in your HA VPN tunnels, your IPv6-enabled VPC networks must include dual-stack subnets. In addition, the subnets must be assigned internal IPv6 ranges.
When you create the VPN tunnels for an IPv6-enabled HA VPN gateway, you must also configure the associated Cloud Router to enable IPv6 prefix exchange in the BGP sessions. Cloud Router uses multiprotocol BGP (MP-BGP) and advertises the IPv6 prefixes over BGP IPv4 addresses. To advertise IPv6 prefixes, the BGP sessions on the Cloud Router require the configuration of IPv6 next hop addresses. You can configure IPv6 next hop addresses for the BGP sessions either automatically or manually.
When you manually configure IPv6 next hop addresses, you must select them
from the 2600:2d00:0:2::/64 or 2600:2d00:0:3::/64 range. These ranges have been pre-allocated by Google. The IPv6 next hop addresses
that you specify must be unique among all Cloud Routers in all regions of a
VPC network.
If you select automatic configuration, Google Cloud creates the IPv6 next hop addresses
for you from the 2600:2d00:0:2::/64 or 2600:2d00:0:3::/64 range.
Although the BGP sessions can exchange IPv6 prefixes, the Cloud Router BGP and BGP peers must be assigned IPv4 addresses, either automatically or manually. IPv6-only BGP sessions are not supported. For details about IPv6 support, see About Cloud Router.
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 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.
Recommended routing option
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 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, 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
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.