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 solutionTo 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 yourselfIf 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 freeTo 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 VPNGoogle Cloud offers two types of Cloud VPN gateways:
HA VPNHA 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.
Note: When you deploy HA VPN over Cloud Interconnect, you have the option of assigning regional internal IP addresses to HA VPN gateway interfaces. You can only use these internal IP addresses for HA VPN gateways that are associated with VLAN attachments. In all other HA VPN gateways, internal IP address assignment is not supported.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:
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 (click to enlarge).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 tableThe following table compares HA VPN features with Classic VPN features.
Note: The tunnel API resource and tunnel configuration remain the same for both Classic VPN and HA VPN. 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. Caution: Dynamic routing or Border Gateway Protocol (BGP) with Classic VPN tunnels will be deprecated on August 1, 2025. For more information, see Feature deprecation: Classic VPN. 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:
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.
Note: You cannot use an RFC 5737 address for the peer IP address.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.
Note: GRE support for VPN has been tested only with GRE version 0. Additionally, support for GRE traffic does not include support from Google Cloud for troubleshooting your overlay networks.HA VPN tunnels support the exchange of IPv6 traffic, but Classic VPN tunnels don't.
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 bandwidthThe 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.
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 IPv6You can disable the creation of all IPv6 hybrid resources in your project by setting the following organization policy to true:
constraints/compute.disableHybridCloudIpv6For 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 sessionsHA 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)To support IPv6 traffic, HA VPN gateways must use either the IPv4 and IPv6 (dual-stack) or IPv6 (single-stack) configuration. To temporarily disable IPv6 traffic without deleting your gateway, disable IPv6 route exchange in the IPv4 BGP session or disable the IPv6 session that you established for the HA VPN tunnels.
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.
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. For information about creating a strong pre-shared key, see Generate a strong 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.
Configure ciphers in Cloud VPN tunnelPreview
This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.
With Cloud VPN, you can configure ciphers that help you tailor your VPN connections to meet compliance and security needs.
You can configure cipher options when you create Cloud VPN tunnels. However, once configured, you cannot modify the selected cipher options later; you must delete and re-create the tunnel. Cipher selection is available only with IKEv2, not IKEv1.
You can configure ciphers for both IKE SA negotiation (phase 1) and IPsec SA negotiation (phase 2). If you don't configure a cipher option for a phase, Cloud VPN uses the default cipher for that option.
You must configure ciphers from the supported list of ciphers that meet the following criteria:
If you specify AEAD ciphers for encryption, you cannot specify separate ciphers for integrity because Cloud VPN uses the same encryption ciphers for handling integrity.
If you specify non-AEAD ciphers for encryption, then you can also specify ciphers for integrity. If you don't specify integrity ciphers, Cloud VPN uses the default cipher options for integrity.
If you specify a mix of both AEAD and non-AEAD ciphers for encryption, you must list the AEAD ciphers before non-AEAD ciphers. Cloud VPN uses the same encryption ciphers for handling integrity for AEAD ciphers.
For non-AEAD ciphers, you can specify the integrity ciphers. If you don't specify integrity ciphers, Cloud VPN uses the default cipher options for integrity.
To learn more about the supported ciphers, default cipher order, and configuration parameters supported by Cloud VPN, see Supported IKE ciphers.
Use the following procedures to configure cipher options (Preview) for the various Cloud VPN gateways:
To configure cipher options for Classic VPN using static routing, see Create a gateway and tunnel.
To configure cipher options for HA VPN to a peer VPN gateway, see Create VPN tunnels.
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-TFor 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 networkBefore 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) supportFor information about using BYOIP addresses with Cloud VPN, see Support for BYOIP addresses.
Active-active and active-passive routing options for HA VPNIf 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 advertisementYour 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.
FailoverIf 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 topologiesIf 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 Note: For an example of a multiple-tunnel active-passive scenario, see Configuring HA VPN for more bandwidth. Caution: We recommend avoiding an active-passive configuration when you have more than two HA VPN tunnels. If you use an active-passive configuration across multiple HA VPN gateways—with an active and passive tunnel pair configured on each gateway—HA VPN doesn't use the passive tunnels for failover until all the active tunnels on all gateways have failed. Configuring multiple gateways with an active-passive configuration can cause bandwidth loss.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 optionWhen 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 tunnelIf 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 connectionsNetwork 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 availabilityCloud 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 practicesTo build your Cloud VPN effectively, use these best practices.
What's nextTo 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.
Learn more about the recommended topologies for HA VPN.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4