This page describes concepts related to Google Cloud VPN.
To create a virtual private network (VPN), see Choosing a VPN Option.
Cloud VPN securely connects your peer network to your Google Cloud Platform (GCP) Virtual Private Cloud (VPC) network through an IPsecVPNconnection. Traffic traveling between the two networks is encrypted by one VPN gateway, then decrypted by the other VPN gateway. This protects your data as it travels over the internet. You can also connect two instances of Cloud VPN to each other.
See the terminology used throughout the Cloud VPN documentation.
Choosing VPN as a hybrid networking solution
See How to choose an Interconnect type to determine whether to use Cloud VPN, Cloud Interconnect – Dedicated, or Cloud Interconnect – Partner as your hybrid networking connection to GCP. This page also covers what type of VPN scenarios Cloud VPN supports.
Types of Cloud VPN
Google Cloud Platform offers two types of Cloud VPN gateways, HA VPN and Classic VPN.
For information on moving to HA VPN, see Moving to HA VPN from Classic VPN.
HA VPN is a high-availability (HA) Cloud VPN solution that let you securely connect your on-premises network to your GCP Virtual Private Cloud network through an IPsec VPN connection in single region. HA VPN provides an SLA of 99.99% service availability (at GA).
When you create an HA VPN gateway, GCP automatically chooses two public 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.
In addition, you don't need to create any forwarding rules for HA VPN gateways.
You can configure an HA VPN gateway with only one active interface and one public IP address; however, this configuration does not provide a 99.99% service availability SLA.
The following diagram shows the HA VPN concept. For more detailed HA VPN topologies (configuration scenarios), see the Cloud VPN Topologies page.
gateways are referred to as
VPN gateways, rather than
target VPN gateways,
in the API documentation and in gcloud commands.
HA VPN requirements
Your Cloud VPN configuration must meet the following requirements to achieve a service-level availability of 99.99% (at GA) for HA VPN:
- When you connect an HA VPN gateway to a non-GCP peer gateway, 99.99% availability (at GA) is guaranteed only on the GCP side of the connection. End-to-end availability is subject to proper configuration of the peer VPN gateway.
- If both sides are GCP gateways and are properly configured, end-to-end 99.99% availability is guaranteed.
- In order 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, the routes to their subnets that they share with each other can be located in any region if your Virtual Private Cloud network uses global dynamic routing mode. If your VPC network uses regional dynamic routing mode, only routes to subnets in the same region are shared with the peer network, and learned routes are applied only to subnets in the same region as the VPN tunnel. For more information about the dynamic routing mode of a VPC network, refer to the VPC networks overview.
- HA VPN rejects GCP IP addresses when they are configured in an external VPN gateway resource. An example of this is using the external IP address of a VM instance as the public IP address for the external VPN gateway resource. The only supported HA VPN GCP-to-GCP topology is where HA VPN is used on both sides, as documented in Creating GCP to GCP HA VPN gateways.
- You must 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 details of an adequately redundant configuration are specified by the device vendor, and may or may not include multiple hardware instances. Refer to the vendor documentation for the peer VPN device for details. 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.
In contrast, Classic VPN gateways have a single interface, a single external IP address, and support tunnels using dynamic (BGP) or static routing (route based or policy 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 gcloud commands.
The following table compares HA VPN features with those for Classic VPN.
|HA VPN||Classic VPN|
|SLA||Provides a 99.99% SLA when configured with two interfaces and two public IPs||Provides a 99.9% SLA|
|Creation of public IPs and forwarding rules||Public IPs created from a pool. No forwarding rules required||Public IPs and forwarding rules must be created|
|Routing options supported||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|
The following terms are used throughout the VPN documentation:
- Project ID
- The ID of your GCP project. A project contains networking resources like networks, subnets, and Cloud VPN gateways as described in the VPC overview. For a description of the difference between project name, project ID, and project number, see Identifying projects. You can view the project id in the Google Cloud Platform Console.
- Google Cloud Platform
- Also known as GCP, Google Cloud Platform is a suite of public cloud computing services offered by Google. Learn about GCP at https://cloud.google.com/products/.
- Cloud VPN gateway
- A virtual VPN gateway running in GCP managed by Google, using a configuration you specify in your project, and used only by you. Each Cloud VPN gateway is a regional resource using one or more regional external IP addresses. A Cloud VPN gateway can connect to a peer VPN gateway as defined below.
- Classic VPN
- The predecessor to the HA VPN gateway. This type of gateway provides a 99.9% availability SLA. See Types of Cloud VPN for details.
- HA VPN
- Replaces Classic VPN with a gateway that provides a 99.99% availability SLA. See Types of Cloud VPN for details.
- Peer VPN gateway
A gateway that is not in GCP and that is connected to a Cloud VPN gateway. A peer VPN gateway can be one of the following:
- Another Cloud VPN gateway
- A VPN gateway hosted by another cloud provider such as AWS or Azure
- An on-premises VPN device or VPN service
- External VPN gateway
- A gateway resource that you configure in GCP for HA VPN that provides information to GCP about your peer VPN gateway or gateways. Depending on the high-availability recommendations from your peer VPN gateway vendor, you can create an external VPN gateway resource for the different types of peer VPN gateways covered on the Topologies page.
- VPN tunnel
- A VPN tunnel connects two VPN gateways and serves as a virtual medium through which encrypted traffic is passed. Two VPN tunnels must be established to create a connection between two VPN gateways: Each tunnel defines the connection from the perspective of its gateway, and traffic can only pass once the pair of tunnels is established. A Cloud VPN tunnel is always associated with a specific Cloud VPN gateway resource.
- As defined for GCP, a logical link between
Cloud VPN and peer VPN locations as identified by
vpnGatewayresource at one end, and an
externalVpnGatewayor another GCP
VpnGatewayresource at the peer end. A connection also includes all of the
vpnTunnelresources and BGP sessions between the gateway resources.
- Internet Key Exchange (IKE)
- IKE is the protocol used for authentication and to negotiate a session key for encrypting traffic.
- Border Gateway Protocol (BGP)
- An exterior gateway routing protocol standardized by the Internet Engineering Task Force (IETF) in RFC 1722. BGP automatically exchanges routing and reachability information among autonomous systems (AS) on the internet. Your device is BGP capable if it can perform BGP routing. This means that you can enable the BGP protocol on it and assign it a BGP IP address and an autonomous system number (ASN). To determine if your device supports BGP, see the vendor information for your device or contact your device's vendor.
- Autonomous system
- A collection of connected IP routing prefixes under the control of a single administrative entity or domain that presents a common routing policy to the internet. For example, an Internet Service Provider (ISP), a large company, or a university.
- A unique identifier allocated to each autonomous system (AS) that uses BGP routing. See RFC 1930 for more information.
Cloud VPN has the following specifications:
- Only public IPv4 addresses are supported for Classic VPN and HA VPN gateways.
- If IP address ranges for on-premise subnets overlap with IP addresses used by subnets in your VPC network, refer to Order of routes to determine how routing conflicts are resolved.
Cloud VPN can be used in conjunction with Private Google Access for on-premises hosts. For more information, see private access options.
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 IP address. You need to know its IP address in order to configure Cloud VPN.
- If your peer VPN gateway is behind a firewall, you must configure the firewall to pass ESP (IPsec) protocol and IKE (UDP 500 and UDP 4500) traffic to it. If the firewall provides Network Address Translation (NAT), refer to 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.
Each Cloud VPN tunnel can support up to 3 Gbps. Actual bandwidth depends on several factors:
- The network connection between the Cloud VPN gateway and your peer gateway:
- The capabilities of your peer VPN gateway. See your device's documentation for more information.
- The packet size: Cloud VPN uses a Maximum Transmission Unit (MTU) of 1460 bytes. Peer VPN gateways must be configured to use a 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. Refer to MTU considerations for a detailed discussion and recommendations.
- The 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
tool, use the
-P parameter to specify the number of simultaneous streams.
IPsec and IKE support
Note that 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.
Cloud VPN only supports a pre-shared key (shared secret) for authentication. You must specify a shared secret when you create the Cloud VPN tunnel. This same secret must be specified when creating the tunnel at the peer gateway. Refer to these guidelines for creating a strong shared secret.
Refer to Supported IKE Ciphers for ciphers and configuration parameters supported by Cloud VPN.
UDP encapsulation and NAT-T
See the UDP and NAT-T section in the Advanced overview for information on how to configure your peer device to support NAT-T with Cloud VPN.
Cloud VPN cannot be used solely as a transit network
Carefully review the GCP Service Specific Terms before you use Cloud VPN.
Do not use Cloud VPN tunnels to connect two or more on-premises networks for the sole purpose of passing traffic through a VPC network as a transit network. Hub-and-spoke configurations like this are a violation of the GCP Service Specific Terms.
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 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.
In an Active/Active routing configuration, the effective aggregate throughput is the combined throughput of both tunnels.
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 as custom dynamic routes in your VPC network with identical priorities. Egress traffic sent to your peer network uses Equal Cost Multi-path (ECMP) routing. The same Cloud Router also advertises routes to your VPC network using identical priorities. Your peer gateway can use these routes to send egress traffic to GCP using ECMP as well.
If one tunnel becomes unavailable, the 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. Additionally, 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.
An Active/Passive routing configuration uses a maximum of one tunnel at a time, so that the second tunnel is able to handle all of your egress bandwidth in the event that the first tunnel fails and needs to be failed over.
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 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 also advertises routes to your VPC network using different priorites for each tunnel. Your peer gateway can also only send traffic to GCP using the tunnel with the highest priority.
If one tunnel becomes unavailable, the 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.
Depending on the peer gateway configuration, it's possible to construct routes such that some traffic would traverse one tunnel and other traffic would traverse 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.
The recommended routing option
With an Active/Passive routing 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, since the observed bandwidth limit stays constant. With an active/active configuration, the observed bandwidth capacity at the time of normal operation is twice that of the guaranteed bandwidth capacity, effectively underprovisioning the tunnels and possibly causing dropped traffic in case of failover.
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 may 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 highly-available VPNs. See the HA VPN topologies page for configuration options. If you are using Classic VPN, see the Classic VPN topologies page for redundancy and high-throughput options.
Use these best practices to build your Cloud VPN in the most effective way.