Networks and tunnel routing (original) (raw)

This page describes supported Virtual Private Cloud (VPC) networks and routing options.

For definitions of terms used on this page, seeKey terms.

Supported networks

Cloud VPN supports custom mode VPC networks, auto mode VPC networks, and legacy networks. However, you should consider the following best practices:

Use VPC networks instead of legacy networks. Legacy networks don't 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 use Cloud VPN to connect two VPC networks, at least one network must be a custom mode VPC network.Auto mode VPC networks use the same range of internal IP addresses for their subnets.
- Review the considerations for auto mode VPC networksbefore using one with Cloud VPN. Auto mode VPC networks automatically create a subnet in each Google Cloud region, including automatically creating new subnets in new regions as they are added. Avoid using the internal IP addresses from the range used by auto mode VPC networks in the network to which Cloud VPN tunnels connect.

Routing options for VPN tunnels

Classic VPN supports static routing options for VPN tunnels, while HA VPN supports the dynamic routing option. You can use Classic VPN tunnels that use dynamic routing only if the Classic VPN gateway connects to VPN gateway software running inside a Compute Engine VM.

Dynamic routing uses theBorder Gateway Protocol (BGP).

Dynamic (BGP) routing

Dynamic routing uses aCloud Router to automatically manage the exchange of routes by using BGP. A BGP interface on a Cloud Router in the same region as the corresponding Cloud VPN tunnel manages this exchange. The Cloud Router adds and removes routes without requiring that the tunnel be deleted and re-created.

The dynamic routing mode of your VPC network controls the behavior of all its Cloud Routers. This mode determines whether the routes learned from your peer network are applied to Google Cloud resources in the same region as the VPN tunnel, or if they are applied in all regions. You control the routes advertised by your peer router or gateway.

The dynamic routing mode also determines whether subnet routes from only the tunnel's region or all regions are shared with your peer router or gateway. In addition to these subnet routes, you can configure custom route advertisementson a Cloud Router.

Static routing

Classic VPN tunnels support policy-based and route-based static routing options. Consider a static routing option only if you cannot use dynamic (BGP) routing or HA VPN.

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 use the Google Cloud console to create a route-based VPN, you only specify a list of remote IP ranges. Those ranges are used only to create routes in your VPC network to peer resources.

You can find more information about these two static routing options in the next section.

Traffic selectors

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 CIDRs forsubnets 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 that emits the VPN tunnel. For Cloud VPN tunnels, the remote traffic selector is the right side or peer network.

Traffic selectors are an intrinsic part of a VPN tunnel, used to establish the IKE handshake. If either the local or remote CIDRs need to be changed, the Cloud VPN tunnel and its peer 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.

HA VPN tunnels
Tunnelrouting option	Localtraffic selector	Remotetraffic selector	Routesto the VPC network	Routesto the peer network
Requiresdynamic (BGP) routing	Always0.0.0.0/0 for IPv4 (single-stack) or 0.0.0.0/0,::/0 for IPv4 and IPv6 (dual-stack) or ::/0 for IPv6 (single-stack)	Always0.0.0.0/0 for IPv4 (single-stack) or 0.0.0.0/0,::/0 for IPv4 and IPv6 (dual-stack) or ::/0 for IPv6 (single-stack)	Unless modified bycustom 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 thedynamic routing mode of the network and quotas and limits for Cloud Router.	Subject to restrictions oncustom routes and thequotas and limits for Cloud Router, the Cloud Router managing the BGP interface for the Cloud VPN tunnel learns routes sent to it by the peer VPN gateway, and adds them to the VPC network ascustom dynamic routes.
Classic VPN tunnels
Tunnelrouting option	Localtraffic selector	Remotetraffic selector	Routesto the VPC network	Routesto the peer network
Dynamic (BGP) routing	Always0.0.0.0/0	Always0.0.0.0/0	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 peer VPN gateway and adds them to the VPC network as custom dynamic routes.
Policy-based routing	Configurable. See policy-based tunnels and traffic selectors.	Required. See policy-based tunnels and traffic selectors.	You must manually create and maintain the routes to the subnets in your VPC network on your peer routers.	If you use the Google Cloud console to create the policy-based VPN tunnel, custom static routes are created automatically. If you use the gcloud CLI to create the tunnel, you must use additional gcloud commands to create the routes. For instructions, seeCreate a Classic VPN using static routing.
Route-based VPN	Always0.0.0.0/0	Always0.0.0.0/0	You must manually create and maintain the routes to the subnets in your VPC network on your peer routers.	If you use the Google Cloud console to create the route-based VPN tunnel, custom static routes are created automatically. If you use the gcloud CLI to create the tunnel, you must use additional gcloud commands to create the routes. For instructions, seeCreate a Classic VPN using static routing.

Policy-based tunnels and traffic selectors

This section describes special considerations for traffic selectors when you create policy-based Classic VPN tunnels. It does not apply to any other type of Classic VPN or HA VPN tunnel.

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 in the VPC network or a set of internal IP addresses that include your chosen IP ranges of subnets in the VPC network. IKEv1 limits local traffic selectors to a single CIDR.
Custom mode VPC networks. Specify a custom local traffic selector that consists of a range of internal IP addresses.
Auto mode VPC networks. If unspecified, the local traffic selector is the primary IP range (CIDR block) of the automatically created subnet in the same region as the Cloud VPN tunnel. Auto mode VPC networks have one subnet per region with well-defined IP ranges.
Legacy networks. If unspecified, the local traffic selector is defined as the entire RFC 1918 IP address range of the legacy network.

Specify the remote traffic selector of a policy-based Cloud VPN tunnel when you create it. If you use the Google Cloud console to create the Cloud VPN tunnel, custom static routes whose destinations correspond to the CIDRs of the remote traffic selector are automatically created. IKEv1limits remote traffic selectors to a single CIDR. For instructions, seeCreate a Classic VPN using static routing.

Important considerations for traffic selectors

Before you create a Cloud VPN policy-based tunnel, consider the following:

Most VPN gateways only pass traffic through a VPN tunnel if the source IP address of a packet fits in the tunnel's local traffic selector, and if the destination IP address of a packet fits in the tunnel's remote traffic selector. Some VPN devices don't enforce this requirement.
Cloud VPN supports traffic selector CIDRs of 0.0.0.0/0 or ::/0(any IP address). To determine if your peer VPN gateway does as well, consult the documentation that came with your peer VPN gateway. Creating a policy-based VPN tunnel with both traffic selectors set to 0.0.0.0/0 or::/0 is functionally equivalent to creating a route-based VPN.
Carefully review multiple CIDRs per traffic selector to learn how Cloud VPN implements IKEv1 and IKEv2 protocols.
Cloud VPN disallows editing any traffic selectors after you have created a VPN. To change either the local or the remote traffic selector for a Cloud VPN tunnel, you must delete the tunnel and then recreate it. You do not have to delete the Cloud VPN gateway, though.
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). This might be the case if you add custom subnets, remove any automatically created subnets, or modify the secondary IP ranges of any subnet. Avoid switching the mode of a VPC network that has existing Cloud VPN tunnels. For suggestions, review the considerations for auto mode VPC networks.

For consistent and predictable VPN behavior, do the following:

Make both the local and remote traffic selectors as specific as possible.
Make the Cloud VPN local traffic selector the same as the remote traffic selector configured for the corresponding tunnel on the peer VPN gateway.
Make the Cloud VPN remote traffic selector the same as the local traffic selector configured for the corresponding tunnel on the on-premises VPN gateway.

Multiple CIDRs per traffic selector

When you create a policy-based Classic VPN tunnel, if you use IKEv2, you can specify multiple CIDRs per traffic selector. Cloud VPN always uses a single Child Security Association (SA), regardless of IKE version.

The following table summarizes Cloud VPN support for multiple CIDRs per traffic selector in policy-based VPN tunnels.

IKE version	Multiple CIDRs per traffic selector
IKEv1	No The IKEv1 protocol only supports a single CIDR per Child SA as defined in RFC 2407 and RFC 2409. Because Cloud VPN requires a single Child SA per VPN tunnel, when you use IKEv1, you can only supply a single CIDR for the local traffic selector and a single CIDR for the remote traffic selector. Cloud VPN does not support creating a VPN tunnel by using IKEv1 with multiple Child SAs, each with a single CIDR.
IKEv2	Yes, if the following conditions are met: Your peer VPN gateway uses a single Child SA. All CIDRs for the local traffic selector and all CIDRs for the remote traffic selector must be in a single Child SA. The number of CIDRs that you configure does not cause IKE proposal packets to exceed Cloud VPN's maximum MTU of 1460 bytes. If IKE proposals exceed this MTU, Cloud VPN tunnels don't establish. You don't exceed any restriction for the number of CIDRs supported by your on-premises gateway. For details, consult your gateway vendor's documentation. A best practice is to use 30 or fewer CIDRs per traffic selector so that you don't create an IKE proposal packet that exceeds the maximum MTU.

IKE version

Multiple CIDRs per traffic selector

IKEv1

No The IKEv1 protocol only supports a single CIDR per Child SA as defined in RFC 2407 and RFC 2409. Because Cloud VPN requires a single Child SA per VPN tunnel, when you use IKEv1, you can only supply a single CIDR for the local traffic selector and a single CIDR for the remote traffic selector. Cloud VPN does not support creating a VPN tunnel by using IKEv1 with multiple Child SAs, each with a single CIDR.

IKEv2

Yes, if the following conditions are met: Your peer VPN gateway uses a single Child SA. All CIDRs for the local traffic selector and all CIDRs for the remote traffic selector must be in a single Child SA. The number of CIDRs that you configure does not cause IKE proposal packets to exceed Cloud VPN's maximum MTU of 1460 bytes. If IKE proposals exceed this MTU, Cloud VPN tunnels don't establish. You don't exceed any restriction for the number of CIDRs supported by your on-premises gateway. For details, consult your gateway vendor's documentation. A best practice is to use 30 or fewer CIDRs per traffic selector so that you don't create an IKE proposal packet that exceeds the maximum MTU.

Traffic selector strategies

Consider the following strategies if your on-premises VPN gateway creates multiple Child SAs per VPN tunnel, or if multiple CIDRs per traffic selector would cause an IKE proposal for IKEv2 to exceed 1460 bytes (for details, seeRouting options and traffic selectors):

Use dynamic routing for the VPN tunnel. If your peer VPN gateway supports BGP, configure both local and remote traffic selectors for the VPN tunnel to allow any IP address. Use 0.0.0.0/0 for IPv4 only or use 0.0.0.0/0,::/0 for IPv4 and IPv6 traffic. Routes are exchanged automatically between the peer VPN gateway and the Cloud Router associated with your Cloud VPN tunnel. If you can use dynamic routing, consider HA VPN.
Use broad, single CIDR traffic selectors and static tunnel routing:
- Use a route-based VPN. Both traffic selectors are0.0.0.0/0 by definition for route-based VPNs. You can create routes that are more specific than the traffic selectors.
- Use policy-based routing and configure the local and remote traffic selectors to be as broad as possible. 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 CIDR blocks specified in the remote traffic selectors. Use the gcloud CLI to create the routes separately from the VPN tunnels by following the steps atCreate a Classic VPN using static routing.
Use policy-based routing to create multiple Cloud VPN tunnels 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 way. Cloud VPN supports multiple tunnels per gateway; however, using multiple tunnels has some implications:
- Your peer VPN gateway must offer separate external IP addresses to which each Cloud VPN tunnel can connect. Tunnels on the same Classic VPN gateway must connect to unique peer gateway IP addresses. Your peer VPN gateway might also require that its tunnels connect to unique IP addresses. In some situations, you need to create a separate Cloud VPN gateway per Cloud VPN tunnel.
- When you use the Google Cloud console to create route-based or policy-based Cloud VPN tunnels, routes to the peer 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 is the case 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 because traffic is delivered to a VPN tunnel according to the applicability and order of routes. If you don't use dynamic (BGP) tunnel routing, create and review static routes in both your VPC network and your peer network.

What's next

To learn about the basic concepts of Cloud VPN, see theCloud VPN overview.
To use high-availability and high-throughput scenarios or multiple subnet scenarios, seeAdvanced configurations.
To help you solve common issues that you might encounter when using Cloud VPN, see Troubleshooting.