This page describes how routing works with different kinds of Google Cloud Platform (GCP) networks. The Overview describes the basic concepts of Google Cloud VPN.
Cloud VPN works with Subnetworks and legacy networks. This page describes the VPN traffic selector, which is a key component of both network types, and highlights the differences of VPN behavior between the network types.
VPN traffic selector
Traffic selector is an agreement between IKE peers concerning which address ranges to permit through a tunnel. These ranges are configured when the tunnel is created and must not be changed afterwards because they are used during the IKE handshake on connect. In some VPN configurations, gateways allow traffic that was not specified in the traffic selector during the IKE handshake. For consistent and predictable VPN behavior, make sure the routes destined for the tunnel match the prefixes specified during tunnel creation.
Local traffic selector ranges govern which ranges are on the Cloud VPN side
of the connection. They are specified in the Local IP ranges
field in the Cloud Platform Console and with the
flag in the
gcloud command-line tool.
Cloud VPN also provides a remote traffic selector field, specified by
--remote-traffic-selector. If this field is specified,
then the VPN can be established before any actual routes are created. This
field should match what is configured on the peer side.
The maximum number of CIDR ranges specified in the traffic selectors is 128.
Multiple CIDR blocks and IKEv1
Cloud VPN does not support putting multiple CIDR blocks into the same IKEv1 tunnel when using static routes.
If you have multiple CIDR blocks that you need to use with VPN, please use any of the following alternatives:
- Use Cloud Router to route the blocks using dynamic routing.
- Use IKEv2 with static routing.
- If possible, unite the CIDR blocks so that you are routing a single, larger block.
- Instead of putting the separate CIDR blocks into the same tunnel, create a separate tunnel for each CIDR block.
- Use route based VPN to allow any traffic through the tunnel, as described in the Simple Setup instructions.
Legacy network behavior
In legacy networks, the recommended practice is to create VPNs to a specific peer network from only one region. Traffic between this peer network and instances in other regions traverse through the region in which the VPN gateway resides.
With a legacy network, the global network is one IP space. Generally, that entire IP space is announced across the VPN tunnel. As a result, if the remote device has several tunnels to the legacy network, it cannot make an informed decision as to which tunnel should be used, and it will chose randomly. This dilemma can create higher costs and longer latencies for packets. For example, if a peer site has one tunnel each from us-central1 and europe-west1, some of the packets from the peer site to instances in us-central1 will travel through europe-west1.
Traffic selector and legacy networks
If your network is a legacy network, the entire network is announced by default to the tunnel. If you want to restrict the announcement to a smaller range of instances, you can use the traffic selector field. However, because the IP addresses for a legacy network aren't allocated predictably across regions, this configuration can result in inefficient performance for your VPN. This performance degradation is due to the impact of equal-cost multi-path routing (ECMP) when using multiple regions as described in the above example.
Subnet network behavior
With subnet networks, instance IP addresses are distributed in predictable ways, so you always know which ranges of IPs will be in a region.
Traffic selector and auto subnet networks
If the network of the VPN gateway is an auto subnet network, the CIDR range of the subnetwork in the same region as the VPN gateway is automatically announced to the peer VPN. If you want only that subnetwork to use the tunnel, you don't have to manually specify the traffic selector.
If you have an auto subnet network and want subnets other than the subnet containing the gateway to use the tunnel, you must specify these ranges and create routes for them. The default behavior is regional routing because global cross-region routing incurs costs.
If you are using an auto subnet network and you don't specify the traffic selector, the subnet local to the Cloud VPN gateway is used to create the tunnel.
Traffic selector and custom subnet networks
If the network of the VPN gateway is a custom subnet network, no IP prefix is announced to the peer VPN, by default. You must use the traffic selector to specify the IP prefixes for the subnetworks that will be routed through the tunnel. You must also specify routes for traffic to reach the tunnel.