This page describes supported Virtual Private Cloud networks and routing options.
Use VPC networks instead of legacy networks. Legacy networks do not support subnets; the entire network uses a single range of IP addresses. Legacy networks cannot be converted into VPC networks.
Use a custom mode VPC network. VPC networks in custom mode provide you with full control over the range of IP addresses used by their subnets.
If you are connecting two VPC networks using Cloud VPN, at least one of them must be a custom mode network because auto mode networks use the same range of internal IP addresses for their subnets.
Review the considerations for auto mode networks before using one with Cloud VPN. Auto mode networks automatically create a subnet in each GCP region, including automatically creating new subnets in new regions as they are added. Avoid using the private IP addresses from the range used by auto mode networks in the network to which Cloud VPN tunnels connect.
Routing options for VPN tunnels
Cloud VPN supports dynamic and static routing options for VPN tunnels. Dynamic routing uses the Border Gateway routing Protocol (BGP).
Dynamic (BGP) routing
Dynamic routing is the preferred method if the on-premises VPN gateway supports BGP. Dynamic routing makes use of a Cloud Router to automatically manage routes. It shares “to GCP” routes with the on-premises VPN gateway and accepts routes to your on-premises network learned from the on-premises gateway. It adds and removes routes using BGP without requiring that the tunnel be deleted and re-created.
On-premises routers are configured to advertise select routes via BGP. The BGP interface on the Cloud Router for the Cloud VPN tunnel learns those routes and applies them to the VPC network according to its dynamic routing mode. The same Cloud Router also shares routes to the VPC network with the on-premises gateway.
Cloud VPN supports both policy based and route based static routing options for VPN tunnels. Consider a static routing option only if you cannot use the dynamic (BGP) routing option for your VPN tunnel:
Policy based routing: Local IP ranges (left side) and remote IP ranges (right side) are defined as part of the tunnel creation process.
Route based VPN: When you create a route based VPN using the GCP Console, you only specify a list of remote IP ranges. Those ranges are only used to create routes in your VPC network to on-premises resources.
Refer to traffic selectors for additional details about these two static routing options.
A traffic selector defines a set of IP address ranges or CIDR blocks used to establish a VPN tunnel. These ranges are used as part of the IKE negotiation for the tunnel. Some literature refers to traffic selectors as “encryption domains.”
There are two types of traffic selectors:
The local traffic selector defines the set of local IP ranges (CIDR blocks) from the perspective of the VPN gateway that emits the VPN tunnel. For Cloud VPN tunnels, the local traffic selector defines the set of primary and secondary subnet IP ranges for subnets in the VPC network, representing the “left side” of the tunnel.
The remote traffic selector defines the set of remote IP ranges (CIDR blocks) from the perspective of the VPN gateway emitting the VPN tunnel. For a Cloud VPN tunnel, the remote traffic selector is the “right side” or on-premises network.
Traffic selectors are an intrinsic part of a VPN tunnel, used to establish the IKE handshake. If either the local or remote IP ranges need to be changed, the Cloud VPN tunnel and its on-premises counterpart tunnel must be destroyed and re-created.
Routing options and traffic selectors
The IP range (CIDR block) values for local and remote traffic selectors depend on the routing option used by the Cloud VPN tunnel:
to the VPC network
to the on-premises network
|Dynamic (BGP) routing||Always
||Unless modified by custom advertisements, the Cloud Router managing the BGP interface for the Cloud VPN tunnel shares the routes to the subnets in the VPC network according to the dynamic routing mode of the network and quotas and limits for Cloud Router.||Subject to restrictions on custom routes and the quotas and limits for Cloud Router, the Cloud Router managing the BGP interface for the Cloud VPN tunnel learns routes sent to it by the on-premises VPN gateway and adds them to the VPC network as custom dynamic routes.|
|Policy based routing||Configurable.
See policy based tunnels and traffic selectors.
See policy based tunnels and traffic selectors.
|You must manually create and maintain the routes to the subnets in your VPC network on your on-premises routers.||Custom static routes are
created automatically if you create the policy based VPN tunnel using the
GCP Console. If you use
|Route based VPN||Always
||You must manually create and maintain the routes to the subnets in your VPC network on your on-premises routers.||Custom static routes are
created automatically if you create the route based VPN tunnel using the
GCP Console. If you use
Policy based tunnels and traffic selectors
This section describes special considerations for traffic selectors when you create policy based Cloud VPN tunnels.
You can choose to specify the local traffic selector of a policy based Cloud VPN tunnel when you create it:
Custom local traffic selector: You can define the local traffic selector as a set of subnets, all subnets in the VPC network, or an IP range that includes the subnets you need.
Custom mode VPC networks: You must specify a custom local traffic selector.
Auto mode VPC networks: If unspecified, the local traffic selector is the IP range of the automatically created subnet in the same region as the Cloud VPN tunnel. Auto mode networks have one subnet per region with well defined IP ranges.
Legacy networks: If unspecified, the local traffic selector is defined as the IP address space for the whole legacy network.
You must specify the remote traffic selector of a policy based Cloud VPN tunnel when you create it. If you create the Cloud VPN tunnel using the GCP Console, custom static routes whose destinations correspond to the IP ranges (CIDR blocks) of the remote traffic selector are automatically created. See Creating a Policy Based VPN for directions.
Because traffic selectors are configurable for policy based VPNs, there are some additional considerations for compatibility:
If you use IKEv1 or if you have to use a single IP range (CIDR block) per traffic selector with IKEv2, you might need to create a “superblock“ for your local or remote traffic selectors. See multiple IP ranges per traffic selector for considerations.
You cannot edit the traffic selectors after you create a Cloud VPN tunnel. If you need to change them, you must delete and re-create the Cloud VPN tunnel (but not the gateway).
If you convert an auto mode VPC network to a custom mode VPC network, you might need to delete and re-create the Cloud VPN tunnel (but not the gateway) if you add or remove subnets or modify the secondary IP ranges for subnets in the VPC network. Switching the mode of a VPC network with existing Cloud VPN tunnels should be avoided. Review the considerations for auto mode networks for suggestions.
Multiple IP ranges per traffic selector
Cloud VPN supports multiple IP ranges (CIDR blocks) in each traffic selector, but only when using IKEv2. The following table summarizes support for multiple IP ranges in traffic selectors:
|IKE Version||Multiple IP ranges per traffic selector
Supported by Cloud VPN
|Multiple IP ranges per traffic selector
Supported by on-premises VPN gateway
The IKEv1 protocol only supports a single IP range (CIDR block) for the local traffic selector and a single CIDR block for the remote traffic selector. This is a limitation of the protocol itself.
|IKEv2||Yes, using a single Child security association (SA)
Cloud VPN supports multiple IP ranges (CIDR blocks) per traffic selector, up to the number that can fit into a single IKE proposal packet whose size is less than or equal to Cloud VPN's maximum MTU of 1,460 bytes.
A best practice is to use 30 or fewer CIDRs per traffic selector so you don't create an IKE proposal packet that would exceed 1,460 bytes.
|Depends on the gateway.
Your gateway must also support multiple CIDR blocks using a single Child SA for compatibility with Cloud VPN, and IKE proposal packets must be 1,460 bytes or less. Your VPN gateway might have additional restrictions on the number of CIDRs per traffic selector; consult its documentation for details.
Traffic selector strategies
Cloud VPN always uses a single Child SA, even with IKEv2 and multiple CIDRs per traffic selector. Thus, you can only use IKEv2 if your on-premises gateway also supports multiple CIDRs using a single Child SA. If your on-premises gateway does not support multiple IP ranges in a single Child SA for IKEv2, or if you have multiple IP ranges in your on-premises network but you must use IKEv1 for your VPN tunnels, consider the following strategies. (These strategies are also useful to reduce the total number of CIDR blocks per traffic selector for VPN tunnels using IKEv2.)
Use dynamic routing for the VPN tunnel. If your on-premises VPN gateway supports BGP, both local and remote traffic selectors for the VPN tunnel are
0.0.0.0/0by definition. Routes are exchanged automatically between the on-premises VPN gateway and the Cloud Router associated with your Cloud VPN tunnel.
Use broad, single IP range (CIDR) traffic selectors and static tunnel routing:
Use a route based VPN. Both traffic selectors are
0.0.0.0/0by definition for route based VPNs. You can create routes that are more specific than the traffic selectors.
Use policy based routing and configure both traffic selectors to be as broad as possible, covering all IP ranges in both the VPC network and the on-premises network. For policy based Cloud VPN tunnels, you can create routes to on-premises networks in your VPC network whose destinations are more specific than the IP range(s) in the remote traffic selectors. The simplest way to accomplish this is to create the routes separately from the VPN tunnels by following
gcloudsteps on the Creating a Policy based VPN page.
Create multiple Cloud VPN tunnels using policy based routing so that each tunnel only has one CIDR block for its local traffic selector and one CIDR block for its remote traffic selector. Configure the on-premises counterpart tunnel in a similar fashion. Cloud VPN supports multiple tunnels per gateway; however, using multiple tunnels has some implications:
- Your on-premise VPN gateway should support multiple tunnels that terminate on the same public IP address so you can use a single Cloud VPN gateway to hold all the tunnels. If it does not, you'll have to use a separate Cloud VPN gateway per Cloud VPN tunnel.
- When you create route based or policy based Cloud VPN tunnels using the GCP Console, routes to the on-premises network are automatically created in addition to the tunnel. If routes are automatically created for multiple VPN tunnels that each use the same remote traffic selectors — as the case will be if you create route based VPNs — you can have multiple routes in your VPC network, all with identical destinations but different next hops. This can lead to unpredictable or unexpected behavior as traffic is delivered to a VPN tunnel according to the applicability and order of routes. You must carefully create and review static routes in both your VPC network and your on-premises network if you don't use dynamic (BGP) tunnel routing.
Most VPN gateways will only pass traffic over a VPN tunnel if the source fits in
the tunnel's local traffic selector and the destination fits in the tunnel's
remote traffic selector. Some VPN devices do not enforce this requirement, and
others support a value of
0.0.0.0/0 (any IP address) for the traffic
selectors. Both the dynamic (BGP) routing option and route based VPNs use broad,
single valued traffic selectors of
For consistent and predictable VPN behavior, make sure that:
The local and remote traffic selectors are as specific as you can. This might not be possible if you're forced to use single valued traffic selectors.
The Cloud VPN local traffic selector should match the remote traffic selector configured for the corresponding tunnel on the on-premises VPN gateway.
The Cloud VPN remote traffic selector should match the local traffic selector configured for the corresponding tunnel on the on-premises VPN gateway.
More VPN concepts
For additional information on Cloud VPN concepts, use the navigation arrows at the bottom of the page to move to the next concept or use the following links:
- Learn about the basic concepts of Cloud VPN
- Choose VPN over other interconnect types
- Redundant and higher-throughput VPNs
- MTU considerations
- Learn about the basic concepts of Cloud VPN
- Create a custom Virtual Private Cloud network
- Set up different types of Cloud VPN
- Maintain VPN tunnels and gateways
- See Advanced Configurations for information on high-availability, high-throughput scenarios, or multiple subnet scenarios.
- Get troubleshooting help