Add a VPN Tunnel to a VPN Connection on GCP

Overview

1. A VPN Connection is an abstraction  (in Google Cloud Platform terms) – while a VPN Tunnel is the implementation. A connection can have one or more tunnels.
2. There are two types of VPNs that you can construct – a HA VPN (uses BGP dynamic routing, preferred due to redundancy) or a classic VPN (requires static route creation and no redundancy / HA is available)

This post highlights the parts that need to be configured (are needed from) the on premises router – as well as those on the GCP side.

1. On the Create a VPN connection page, specify the following gateway settings:
   • Name — The name of the VPN gateway. The name cannot be changed later.
   • Description — Optionally, add a description.
   • Network — Specify an existing VPC network in which to create the VPN gateway and tunnel.
   • Region — Cloud VPN gateways and tunnels are regional objects. Choose a Google Cloud region where the gateway will be located. Instances and other resources in different regions can use the tunnel for egress traffic subject to the order of routes. For best performance, locate the gateway and tunnel in the same region as relevant Google Cloud resources.
   • IP address — Create or choose an existing regional external IP address.

Configure Tunnels – Route based versus Policy based

What decides whether you go route based or policy based? Two key factors:

1. What is your on premises VPN gateway capable of doing? In most cases, it can only do policy based (which is an access-list that defines the tunneled traffic)
2. Can your on prem router handle BGP routing. The ‘route based’ requires some BGP configuration – even if you use ‘static routing’  (not dynamic routing)

What is needed from the on premises network?

1. 1. 1. Does it support route based vpn tunnels or policy based vpn tunnels?
      2. What is the Remote peer IP address — Specify the public IP address of the peer VPN gateway.
      3. What is the IKE version — Choose the appropriate IKE version supported by the peer VPN gateway. IKEv2 is preferred if it’s supported by the peer device.
      4. What is the Shared secret — Provide a pre-shared key used for authentication. The shared secret for the Cloud VPN tunnel must match the one used when you configure the counterpart tunnel on the peer VPN gateway. You can follow these directions to generate a cryptographically strong shared secret.
      5. Remote network IP ranges — Provide a space-separated list of the IP ranges used by the peer network. These ranges are used to create custom static routes whose next hop is this VPN tunnel.

Setting up a new tunnel

Specify the following settings in the Tunnels section for the new tunnel:

• • Name — The name of the VPN tunnel. The name cannot be changed later.
  • Description — Optionally, type a description.
  • Route based versus Policy based (see section above)

Static IPs on both sides

The public IP address created by GCP will be needed on the customer VPN router. The customer VPN IP is needed by the GCP VPN connection.

Policy based tunnels

1. For Policy based tunnels ( do not need any BGP setup)
   • Under Routing options, select Policy-based.
   • Under Remote network IP ranges, provide a space-separated list of the IP ranges used by the peer network. This is the remote traffic selector: the “right side” from the perspective of Cloud VPN.
   • Under Local IP ranges, select one of the following methods (you only need ONE of these two options . option B allows you to pre-specify the ENTIRE VPC address block):
     • Use the Local subnetworks menu to choose an existing local IP range, or
     • Use the Local IP ranges field to enter a list of space-separated IP ranges used in your VPC network (this can include the ENTIRE VPC network address space). Refer to traffic selectors for important considerations.
2. The fields  below are all relevant to the on premises router
   • • Remote network IP ranges — Provide a space-separated list of the IP ranges used by the peer network. These ranges are used to create custom static routes whose next hop is this VPN tunnel.
3. If you need to create more tunnels on the same gateway, click Add tunnel and repeat the previous step. You can also add more tunnels later

Testing out your cloud VPN Tunnel

1. Check that the inbound ICMP firewall rule is set (ICMP is neither TCP nor UDP – it is it’s own protocol…just need ICMP and other fields left blank)
2. Check inbound SSH is allowed (from 0.0.0.0/0 to all instances in the VPC).
3. Spin up an instance (ensure the  ‘network interface’ belongs to the correct VPC – and the region is the same as the region the VPC was spun up in).
4. From a computer in your network that is behind the customer gateway, use the ping command with the instance’s private IP address.
   1. private IP address (for example, 10.0.0.4). try pinging it. This success means that the tunnel is correct – and the ping is going through the tunnel.
   2. Get the external IP address (try pinging it). This success does not mean the tunnel is set up right.

Summary

A classic VPN is a top level resource in GCP that can contain one or more tunnels. Each tunnel can be either route based or policy based. This is driven mostly by the on premises vpn gw router – and what it supports. This post summarizes a quick recap of what is needed from the on premises network and what is needed on the GCP side to create a  classic VPN in GCP.