This page describes advanced configuration details that most users shouldn't need. The Overview describes the basic concepts of Cloud VPN.
While many VPNs can be configured using only the steps outlined in Creating a VPN, some users need additional details. Such details are provided here.
Advanced settings and configurations
Security associations and multiple subnets
Cloud VPN creates a single child security association (SA) announcing all CIDR blocks associated with the tunnel. Some IKEv2 peer devices support this behavior, and some only support creating a unique child SA for each CIDR block. With these latter devices, tunnels with multiple CIDR blocks can fail to establish.
There are several workarounds for this issue:
- Use Cloud Router to create BGP-negotiated routes. With this configuration, the CIDRs are not negotiated in the IKE protocol.
- Disable CIDR configuration in the IKE protocol by setting the CIDR blocks to 0.0.0.0/0. This setup is called "Route-based VPN"). See the Simple setup instructions.
- Configure the peer device to have several CIDRs in the same child SA. Only some devices support this, and it is only possible in IKEv2.
- If possible, aggregate the CIDRs into a single, larger CIDR.
- Create a separate tunnel for each CIDR block. If necessary, you can create several VPN gateways for this purpose.
All on-premises subnets connected to the same tunnel must use the same child SA. If different on-premises subnets do not have the same SA, they must be connected to different tunnels.
When egressing from on-premises the routing to Cloud VPN and the choice of child SA within Cloud VPN are done based on destination IP only. This affects architecture choices. For instance, configuring two child SAs that have the same on-premises CIDR block and different GCP CIDR blocks may not produce the desired effect. Similarly, connecting the same on-premises CIDR with two different GCP CIDRs using two different tunnels may not produce the desired effect.
Supported IKE ciphers
The following are supported ciphers for IKEv2 and IKEv1.
IKEv2 supported ciphers
|Phase 1||Encryption||aes-cbc, aes-ctr each with keys of 128,192,256
aes-gcm, aes-ccm with same key lengths and IVs of size 8,12,16
|Integrity||sha1-96, sha2-256-128, sha2-384-192, sha2-512-256, md5, xcbc-96, cmc-96|
|prf||sha1-96, sha2-256-128, sha2-384-192, sha2-512-256, md5, xcbc-96, cmc-96|
|Diffie-Hellman (DH)||For most IKEv2 devices, this value is auto-negotiated and
so should be left unset. If your device
requires it to be set, use one of the following values:
Group 2 (modp_1024), Group 5 (modp_1536), Group 14 (modp_2048), Group 15 (modp_3072), Group 16 (modp_4096), Group 18 (modp_8192), modp_1024s160, modp_2048s224, modp_2048s256
|Phase 1 lifetime||36,000 seconds (10 hours)|
|Phase 2||Encryption||aes-cbc-128, aes-cbc-192, aes-cbc-256, aes-128-gcm-8, aes-128-gcm-12, aes-128-gcm-16|
|PFS Algorithm||Group 2 (modp_1024), Group 5 (modp_1536), Group 14 (modp_2048), Group 15 (modp_3072), Group 16 (modp_4096), Group 18 (modp_8192), modp_1024s160, modp_2048s224, modp_2048s256|
|Phase 2 lifetime||10,800 seconds (3 hours)|
IKEv1 supported ciphers
|PFS Algorithm||Group 2 (modp_1024)|
|Diffie-Hellman (DH)||Group 2 (modp_1024)|
|Phase 1 lifetime||36,600 seconds (10 hours, 10 minutes)|
|Phase 2 lifetime||10,800 seconds (3 hours)|
Maximum Transfer Unit (MTU) considerations
While TCP Path MTU Discovery usually takes care of MTU considerations automatically, you might have to set your MTU manually in some cases.
The Cloud VPN MTU is 1460. The MTU of the peer VPN device must be set to 1460 or lower. ESP packets leaving the device must not exceed 1460 bytes. You must enable prefragmentation on your device, which means that packets must be fragmented first, then encapsulated.
If your peer device is generating ESP packets larger than 1460, you have two options:
- Determine a lower workable MTU for your protocol and set the MTU appropriately.
- Allow the peer gateway to prefragment large packets before encapsulating.
To do this, make sure the DF bit is off before sending packets to
Cloud VPN only supports prefragmentation of large packets. It does not support large packets that have been encapsulated, then fragmented.
Cloud VPN has replay detection enabled, and there is no way to turn it off. The Cloud VPN replay window is 4096 packets.
VPN supports UDP encapsulation, which is commonly used in NAT-T configurations. However, the Cloud VPN gateway expects to receive traffic sent by the configured remote side peers only and will ignore traffic from other sources.
Tunnels with overlapping IP ranges
It is possible to create a tunnel that has the same IP range as another tunnel, a subset of the other tunnel's range, or a superset of the other tunnel's range.
If the two tunnels do not have matching CIDR blocks, Cloud VPN picks the tunnel that has the more specific block. If the two tunnels do have matching CIDR blocks, then Cloud VPN uses ECMP to balance flows between the two tunnels. The balancing is based on a hash, so all packets from the same flow use the same tunnel.
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.
VPN maintenance cycles
VPN will undergo maintenance cycles periodically. During these short periods, VPN Gateways and tunnels will not serve traffic. The maintenance logic ensures that, for a given project, only one VPN gateway within a region are serviced at any given time. Tunnels automatically reconnect after the maintenance cycle completes. For more information about VPN availability, refer to the VPN SLA.
Redundancy and failover
If a Cloud VPN tunnel goes down, it restarts automatically. If an entire virtual device fails, Cloud VPN automatically instantiates a new one with the same configuration. The new gateway and tunnel connect automatically.
If your peer side is hardware based, having a second peer-side gateway provides redundancy and failover on that side of the connection as well. A second physical gateway allows you to take one of them offline for software upgrades or other scheduled maintenance. It also protects you in case of an outright failure in one of the devices.
To configure a tunnel from your Cloud VPN gateway to a second peer-side VPN gateway, do the following:
- Configure a second peer VPN gateway and a tunnel.
- Set up a second tunnel on your Cloud VPN gateway pointing to the second peer gateway.
- Forward the same routes for the second tunnel as you did for the first. If you want both tunnels to balance traffic, set their route priorities to be the same. If you want one tunnel to be primary, set a lower priority on the second tunnel.
- If either VPN tunnel fails due to network issues along the path or a problem with a peer gateway, the Cloud VPN gateway will continue sending traffic over the healthy tunnel and will automatically resume using both tunnels once the failed tunnel recovers.
Each Cloud VPN tunnel can support up to 3 Gbps when the traffic is traversing a direct peering link, or 1.5 Gbps when traversing the public Internet. Actual performances vary depending on the following factors:
- Network capacity between the two VPN peers.
- The capabilities of the peer device. See your device's documentation for more information.
- Packet size. Because processing happens on a per-packet basis, having a significant percentage of smaller packets can reduce overall throughput.
- High RTT and packet loss rates can greatly reduce throughput for TCP.
Recommended measures to increase VPN throughput
When measuring throughput in TCP streams, it is better to also measure more than one
TCP stream. For instance, if you are measuring using the
iperf tool, you should
-P parameter to add multiple streams.
VPN connectivity can be configured to achieve high throughput when the negotiated child-SA is using an encryption and authentication algorithm called AES-GCM. This algorithm can be negotiated with the Cloud VPN gateway when using IKEv2. However, if there are reasons not to use the recommended algorithm, other algorithms can be supported through the VPN gateway’s negotiation process.
It is important to understand the peer VPN gateway’s throughput limitations and ensure appropriate throughput levels are supported by the peer VPN gateway.
If your peer VPN gateway’s throughput capabilities are higher, and you would like to scale higher throughput from Cloud VPN gateway, you can set up a second VPN gateway, as shown in option 2 below. You can also combine these strategies, as in option 3 below.
Option 1: Configure to scale your peer VPN gateway
Set up a second peer VPN gateway device with a different public IP address. Create a second tunnel on your existing Cloud VPN gateway that forwards the same IP range, but pointing at the second peer gateway IP. Your Cloud VPN gateway automatically load balances between the configured tunnels. You can set up the VPN gateways to have multiple tunnels load balanced this way to increase the aggregate VPN connectivity throughput.
Option 2: Configure to scale the Cloud VPN gateway
Add a second Cloud VPN gateway on the same region similar to the existing VPN gateway. The second Cloud VPN gateway can have a tunnel that points to the same IP address of the peer VPN gateway as the tunnel on the first gateway. Once configured, traffic to the peer VPN gateway is automatically load balanced between the two Cloud VPN gateways and tunnels.
Option 3: Scale at both the peer VPN gateway and the Cloud VPN gateway
Combine options 1 and 2 mentioned above to scale throughput. If you have two peer VPN gateways and two Cloud VPN gateways, each Cloud VPN gateway can have a tunnel pointing at each peer VPN gateway public IP, giving you four load balanced tunnels between the VPN gateway thereby potentially increasing four times the bandwidth.