This page describes how routes for Cloud VPN tunnels are interpreted in VPC and legacy networks. Review the Routes Overview for important background information about routes in GCP. This document assumes that you understand route applicability and order.
VPN routes define an egress path for traffic leaving your GCP network:
Routes for Cloud VPN tunnels using dynamic routing are managed by a Cloud Router. These routes cannot be edited or removed manually. Routes with destinations to peer networks are automatically created and removed by the Cloud Router associated with the tunnel based on the BGP advertisements of the peer VPN gateway. The next hop for a dynamic route is the BGP IP address of the peer.
If you use the GCP Console to create tunnels using policy based routing or route based VPNs, GCP creates a static route with a matching destination for each IP range in the remote traffic selector. If you create the tunnels using
gcloudcommands, you must manually create the corresponding static routes. The next hop for a VPN static route is the appropriate Cloud VPN tunnel.
GCP follows a specific procedure for selecting the next hop for a packet. The following examples illustrate how VPN routes work in conjunction with subnet routes. For more information about how GCP selects a specific route, see Routing order in the VPC documentation.
In each example,
10.2.0.0/16 represents an on-premises network IP address
GCP subnet with the same IP range: If your GCP network contains a subnet using the
10.2.0.0/16range, GCP prevents you from creating a Cloud VPN tunnel using policy based routing or route based VPN if a remote traffic selector includes
10.2.0.0/16. If the Cloud VPN tunnel uses dynamic routing, the associated Cloud Router ignores any advertised routes with a destination of
10.2.0.0/16. Traffic destined for
10.2.0.0/16remains in GCP.
GCP subnet with a broader IP range: If your GCP network contains a subnet using a larger, encompassing IP range such as
10.0.0.0/8, GCP prevents you from creating a Cloud VPN tunnel using policy based routing or route based VPN if a remote traffic selector includes
10.0.0.0/8or a more specific range. If the Cloud VPN tunnel uses dynamic routing, the associated Cloud Router ignores any advertised routes with destinations that fit in
10.0.0.0/8(including more specific ranges). All traffic destined for
10.0.0.0/8remains in GCP.
GCP subnet with a narrower IP range: If your GCP network contains a subnet with a narrower, included IP range like
10.2.99.0/24, you can create a Cloud VPN tunnel to the broader
10.2.0.0/16range using any routing option: Traffic destined to
10.2.99.0/24is still routed to the GCP subnet. Traffic destined to
10.2.0.0/16but outside of
10.2.99.0/24(such as to
10.2.100.8) is sent through the VPN tunnel.
With other VPN routes
If no destination is found with a subnet route, GCP resolves routes for VPN tunnels in the following way:
Routes that use a Cloud VPN tunnel as a next hop are ignored if the tunnel is not up.
GCP sends the packet to the next hop of the route with the most specific destination.
If more than one route has the same most-specific destination, the priority of the route is used:
If a single route with the highest priority is available, the packet is sent to its next hop.
If more than one route has the same highest priority, the packet is delivered to the next hop of either route using ECMP. This means that traffic is distributed among multiple next hops, so it is balanced among the applicable, available Cloud VPN tunnels. This balancing method is based on a hash, so all packets from the same flow use the same tunnel as long as that tunnel is up.
To test ECMP behavior, use iperf3 to send multiple simultaneous TCP streams, ideally from multiple GCP VMs, through Cloud VPN tunnels.
Using ICMP to "ping test" from one VM instance isn't sufficient to test ECMP-based egress through Cloud VPN tunnels, since only one tunnel is selected when you run
ping. This is because ICMP (ping) has no concept of ports and is a fixed protocol. This results in a 2-tuple that contains only a source and destination IP address and that always selects a single tunnel.
When tunnels are down
When Cloud VPN tunnels are not available, GCP interprets their associated routes as follows:
If a Cloud VPN tunnel uses dynamic routing, its associated Cloud Router automatically removes the learned routes when the tunnel goes down. The learned routes are those with a next hop of the BGP IP for the corresponding peer VPN gateway. Provided there are no conflicts with subnet routes, the learned routes are re-added when the tunnel comes back up. Depending on your network, it can take the associated Cloud Router up to 40 seconds of processing time to remove them.
Tunnels using policy based routing or route based VPNs have corresponding static routes. GCP ignores static routes with next hops that point to Cloud VPN tunnels that are down.
If a second Cloud VPN tunnel provides an alternate path to the same destination, you should still expect packet loss whenever one Cloud VPN tunnel goes down. In-flight packets may be dropped, and dynamic routes are removed only after the associated Cloud Router has completed its processing.
- 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.
- View logs and monitoring metrics
- Get troubleshooting help