Virtual Private Network (VPN)

Google Compute Engine VPN lets you connect your existing network to your Compute Engine network via an IPsec connection. Alternatively, you can use it to connect two different Google Compute Engine VPN gateways.

Knowledge of Compute Engine networks, routes, and protocol forwarding is useful for understanding how your VPN gateway fits into your Compute Engine network.

• Site-to-site VPN is supported. You can have multiple tunnels to a single VPN gateway.
• Static routes, for managing traffic between your Compute Engine virtual machines and your existing infrastructure, are supported.
• Compute Engine VPN uses ESP in Tunnel mode with authentication. AH and ESP in Transport mode are not supported.
• Internet Key Exchange, both IKEv1 and IKEv2, is supported using a shared secret.

Contents

Beta

Beta Access

To get access to beta functionality, update your client by running the following command:

$ gcloud components update beta

Beta Pricing

^* Not charged during Beta.

Compute Engine does not charge for forwarding rules that send traffic to the VPN gateway.

Beta Limitations

The following limitations apply to the Beta release:

• VPN gateways can be created in the us-central1, europe-west1, and asia-east1 regions only.
• This release doesn’t support VPN "road warrior" scenarios. Usage is limited to site-to-site IPsec VPN only.

Terminology

The following terms are used in this document:

• Compute Engine VPN gateway — the virtual VPN gateway running in Compute Engine. This virtual device is managed by Google, but used only by you.
• Customer VPN gateway — the other side of the connection. Frequently a physical device on your premises. However, it can be a second Google Compute Engine VPN device.
• Project ID — the Compute Engine-generated Project ID, not the Project Name supplied by you.
• Shared Secret — The shared secret can be a mixture of letters and numbers. The shared secret seeds the IKE key exchange.

Requirements

The following are requirements you must complete before you can use VPN.

• Identify the Compute Engine project and region where you would like to create VPN resources. The region must be one of the regions supported for the alpha phase — us-central1, europe-west1, and asia-east1.
• You must have a Customer VPN gateway to complete the tunnel. This gateway may be a physical or virtual gateway on your premises, or it may be a second Compute Engine VPN.
• The Customer VPN gateway must have a static external IP address. You'll need to know the IP address when you configure the VPN in Compute Engine. If the Customer VPN gateway is behind a firewall, you must configure the firewall to pass ESP and IKE traffic.
• The CIDR range of the network on the Compute Engine side of the VPN must not conflict with the CIDR range(s) of the network(s) on the Customer side of the VPN.
• You must supply a shared secret for the VPN. This can either be provided by your existing customer VPN gateway or you can make one up.
• Compute Engine VPN supports both IKEv2 (recommended) and IKEv1. Determine what your Customer VPN gateway supports.

Creating a VPN using the Google Developers Console

These steps walk you through creating a Compute Engine VPN gateway and tunnel, configuring your Compute Engine firewall to allow the VPN traffic, and confirming that the tunnel has come up as expected.

Create the gateway and a tunnel

First, create a Compute Engine VPN gateway and a tunnel pointing to your Customer VPN gateway.

1. Choose a project from the Google Developers Console.
2. Under Networking, select VPN.
3. Click Create a VPN.
4. Populate the following fields for the gateway itself:
   • Name — The name of the VPN gateway. This name is displayed in the console and used in all gcloud commands to reference the gateway.
   • Description — Optional freeform text field.
   • Network — The Compute Engine network the VPN gateway will exist in.
   • Region — Ordinarily, this will be the region containing the bulk of your instances.
   • IP Address — Select a pre-existing static external IP address or reserve a new one.
5. Populate fields for at least one tunnel:
   • Peer IP address — Public IP address of the other gateway.
   • IKE version — IKEv2 is prefered, but IKEv1 is supported if that is all the other gateway can manage.
   • Shared Secret — Seeds the IKE key exchange for that tunnel.
   • Remote Network IP Range — The range, or ranges, of the peer network. This is the range or ranges your Compute Engine gateway forwards across the VPN tunnel.
6. If you wish to create additional tunnels, click the + button.
7. Click Create to create the Gateway and bring up all tunnels.
   This step automatically creates the necessary routes and forwarding rules for the gateway and tunnels.

Configure firewall rules

Now that you have your VPN gateway set up, configure your Compute Engine firewall to allow VPN traffic.

1. Once the gateway and tunnel are created, select Networking > VPN to see the tunnels in that project.
2. Click Configure in the Firewall Rules column of the new tunnel.
   This takes you to a configuration page for the network containing the tunnel.
3. Click New Firewall Rule. Add a rule for TCP:
   • NAME: allow-tcp
   • DESCRIPTION: Any text you like.
   • SOURCE FILTER: IP ranges
   • SOURCE IP RANGES: 0.0.0.0/0
   • ALLOWED PROTOCOLS OR PORTS: tcp
   • TARGET TAGS: Any valid tag or tags.
4. Click Create.
5. Click New Firewall Rule. Add a rule for UDP:
   • NAME: allow-udp
   • DESCRIPTION: Any text you like.
   • SOURCE FILTER: IP ranges
   • SOURCE IP RANGES: 0.0.0.0/0
   • ALLOWED PROTOCOLS OR PORTS: udp
   • TARGET TAGS: Any valid tag or tags.
6. Click Create.
7. Click New Firewall Rule. Add a rule for ICMP:
   • NAME: allow-icmp
   • DESCRIPTION: Any text you like.
   • SOURCE FILTER: IP ranges
   • SOURCE IP RANGES: 0.0.0.0/0
   • ALLOWED PROTOCOLS OR PORTS: icmp
   • TARGET TAGS: Any valid tag or tags.
8. Click Create.
9. Create other firewall rules if necessary.

Set up the Customer VPN gateway

Set the IKE values on your Customer VPN gateway.

Check the status of your tunnel

Check on the status of your tunnel by going to Networking > VPN in the developer console. A checkmark appears next to the PEER IP ADDRESS field if your gateways have successfully negotiated a tunnel. If no checkmark appears, see Troubleshooting.

Creating a VPN gateway and tunnel using gcloud compute

This section walks you through creating a Compute Engine VPN gateway and tunnel, configuring your Compute Engine firewall to allow the VPN traffic, and confirming that the tunnel has come up as expected.

This diagram shows a simple VPN connection between your Compute Engine VPN gateway and your Customer VPN gateway. It should help clarify some of the steps below.

1. Choose or create a Compute Engine network. You can use any RFC1918 range, but this network must not conflict with the IP range in your customer-side network.

   $ gcloud beta compute --project PROJECT networks create \
            --range 10.120.0.0/16 network1
   
   NAME     IPV4_RANGE    GATEWAY_IPV4
   network1 10.120.0.0/16 10.120.0.1
   

2. Create a VPN gateway in the desired region. This step creates an unconfigured virtual VPN gateway named vpn1 in your Compute Engine network.

   $ gcloud beta compute --project PROJECT target-vpn-gateways create \
            --region us-central1 \
            --network network1 vpn1
   
   NAME NETWORK  REGION
   vpn1 network1 us-central1
   

3. Reserve a static IP address in the Compute Engine network and region where you created the VPN gateway. Make a note of the created address for use in future steps.

   $ gcloud beta compute --project PROJECT addresses create \
            --region us-central1 vpn-static-ip
   
   NAME          REGION      ADDRESS         STATUS
   vpn-static-ip us-central1 ipaddress1      RESERVED
   
   vpn-static-ip ~> ipaddress1
   

4. Create a forwarding rule that forwards ESP traffic toward the Compute Engine VPN gateway. Use the static IP address (VPN_STATIC_IP_ADDRESS) reserved earlier. This step generates a forwarding rule named fr-esp.

   $ gcloud beta compute --project PROJECT forwarding-rules create \
            --region us-central1 \
            --ip-protocol ESP \
            --address VPN_STATIC_IP_ADDRESS \
            --target-vpn-gateway vpn1 fr-esp
   
   NAME   REGION      IP_ADDRESS      IP_PROTOCOL TARGET
   fr-esp us-central1 ipaddress1      ESP         us-central1/targetVpnGateways/vpn1
   

5. Create a forwarding rule that forwards UDP:500 traffic to the Compute Engine VPN gateway. Use the static IP address (VPN_STATIC_IP_ADDRESS) reserved earlier. This step creates a forwarding rule named fr-udp500.

   $ gcloud beta compute --project PROJECT forwarding-rules create \
            --region us-central1 \
            --ip-protocol UDP \
            --port 500 \
            --address VPN_STATIC_IP_ADDRESS \
            --target-vpn-gateway vpn1 fr-udp500
   
   NAME      REGION      IP_ADDRESS      IP_PROTOCOL TARGET
   fr-udp500 us-central1 ipaddress1      UDP         us-central1/targetVpnGateways/vpn1
   

6. Create a forwarding rule that forwards UDP:4500 traffic to the Compute Engine VPN gateway. Use the static IP address (VPN_STATIC_IP_ADDRESS) reserved earlier. This step creates a forwarding rule named fr-udp4500.

   $ gcloud beta compute --project PROJECT forwarding-rules create \
            --region us-central1 \
            --ip-protocol UDP \
            --port 4500 \
            --address VPN_STATIC_IP_ADDRESS \
            --target-vpn-gateway vpn1 fr-udp4500
   
   NAME       REGION      IP_ADDRESS      IP_PROTOCOL TARGET
   fr-udp4500 us-central1 ipaddress1      UDP         us-central1/targetVpnGateways/vpn1
   

7. Create a VPN tunnel on the Compute Engine VPN Gateway that points toward the external IP address (CUST_GW_EXT_IP) of your customer VPN gateway. You also need to supply the shared secret. The default, and preferred, IKE version is 2. If you need to set it to 1, use --ike_version. The following example sets IKE version to 2. Once this command is executed, resources are allocated for this VPN tunnel, but it is not yet passing traffic.

   $ gcloud beta compute --project PROJECT vpn-tunnels create \
            --region us-central1 \
            --peer-address CUST_GW_EXT_IP \
            --ike-version 2 \
            --shared-secret SHAREDSECRET \
            --target-vpn-gateway vpn1 tunnel1
   
   NAME    REGION      GATEWAY PEER_ADDRESS
   tunnel1 us-central1 vpn1    CUST_GW_EXT_IP
   

8. Configure the destination range of IP addresses (CIDR_DEST_RANGE) to route traffic through the VPN tunnel to your local network. You can repeat this command to add multiple ranges to the VPN tunnel. The region must be the same as specified in the step Create the VPN tunnel.

   $ gcloud beta compute --project PROJECT routes create \
            --network network1 \
            --next-hop-vpn-tunnel tunnel1 \
            --next-hop-vpn-tunnel-region us-central1 \
            --destination-range CIDR_DEST_RANGE route1
   
   NAME   NETWORK  DEST_RANGE       NEXT_HOP PRIORITY
   route1 network1 CIDR_DEST_RANGE           1000
   

9. Configure the firewall on the Compute Engine network to allow traffic from your Customer network to your Compute Engine virtual machines. If you have more than one Customer network range, provide a space-separated list in the source-ranges field (--source-ranges 10.10.5.1/24)

   $ gcloud beta compute --project PROJECT firewall-rules create vpnrule1 \
            --network network1 \
            --allow tcp udp icmp \
            --source-ranges CIDR_DEST_RANGE
   

10. Configure your local device:

    For IKEv1 and IKEv2:

    Parameter	Value
    IPsec Mode	ESP+Auth Tunnel mode
    Auth Protocol	psk
    Shared Secret	Choose a strong password. The shared secret is very sensitive as it allows access into your network.
    Start	auto (customer device should automatically restart the connection if it drops)
    PFS (Perfect Forward Secrecy)	on
    DPD (Dead Peer Detection)	Recommended: Aggressive. DPD detects when the Compute Engine VPN restarts and route traffic using alternate tunnels.
    INITIAL_CONTACT (sometimes called uniqueids)	Recommended: on (sometimes called ‘restart’). The purpose is to detect restarts faster so that perceived downtime is reduced.

    Additional parameters for IKEv1 only:

    Parameter	Value
    IKE/ISAKMP	aes128-sha1-modp1024
    ESP	aes128-sha1
    PFS Algorithm	Group 2 (MODP_1024)

11. Confirm that the tunnel is up.

    $ gcloud beta compute --project PROJECT vpn-tunnels describe \
             --region us-central1 tunnel1
    
    creationTimestamp: '2014-11-26T04:38:28.260-08:00'
    description: ''
    detailedStatus: 'Tunnel is up and running..  More info: <link to more info>'
    id: 'ID'
    ikeVersion: 2
    kind: compute#vpnTunnel
    name: tunnel1
    peerIp: CUST_GW_EXT_IP
    region: region1
    selfLink: <link to tunnel resource>
    sharedSecret: SHAREDSECRET
    sharedSecretHash: AFWI5mBld5swmCciGVEU1IO6lfJs
    status: ESTABLISHED
    targetVpnGateway: <IP address of resource>
    

The Status field shows one of the following results.

    $ gcloud beta compute --project PROJECT forwarding-rules list --region us-central1
    NAME       REGION      IP_ADDRESS      IP_PROTOCOL TARGET
    forward1   us-central1 173.255.115.137 TCP         us-central1/targetPools/pool1
    fr-esp     us-central1 130.211.116.215 ESP         us-central1/targetVpnGateways/vpn1
    fr-udp4500 us-central1 130.211.116.215 UDP         us-central1/targetVpnGateways/vpn1
    fr-udp500  us-central1 130.211.116.215 UDP         us-central1/targetVpnGateways/vpn1

    $ gcloud beta compute --project PROJECT routes list
    NAME                           NETWORK  DEST_RANGE       NEXT_HOP                 PRIORITY
    default-route-044ea64475ed089f default  0.0.0.0/0        default-internet-gateway 1000
    default-route-32610888d82a7e33 default  10.240.0.0/16                             1000
    default-route-5f2161531059c062 network1 0.0.0.0/0        default-internet-gateway 1000
    default-route-672665719a1ec4c5 network1 10.120.0.0/16                             1000
    route1                         network1 192.168.100.0/24                          1000

Adding a tunnel to an existing gateway

Follow the steps for creating a VPN gateway and tunnel, but start with step 7, Create the VPN tunnel. If the new tunnel has the same CIDR block, you can skip step 9, Adding firewall rules.

Deleting a tunnel

To delete an existing tunnel from a VPN gateway, do the following:

1. If desired, delete all routes. Run the following command once for each route. You do not have to delete the routes first, or at all, but your network will continue forwarding packets to the external IP until you do.

   $ gcloud beta compute --project PROJECT routes delete ROUTE
   

2. Delete the tunnel.

   $ gcloud beta compute --project PROJECT vpn-tunnels delete \
            --region us-central1 tunnel1
   

Deleting a gateway

To delete an existing VPN gateway, you must also delete resources associated with the gateway.

1. Delete all tunnels. Follow the instructions in Deleting a Tunnel for each tunnel.

2. Delete the ESP, UDP:500, and UDP:4500 forwarding rules.

   $ gcloud beta compute --project PROJECT forwarding-rules delete \
            --region us-central1 fr-esp
   $ gcloud beta compute --project PROJECT forwarding-rules delete \
            --region us-central1 fr-udp500
   $ gcloud beta compute --project PROJECT forwarding-rules delete \
            --region us-central1 fr-udp4500
   

3. Delete the firewall rule that allowed TCP, UDP, and ICMP traffic.

   $ gcloud beta compute --project PROJECT firewall-rules delete vpnrule1
   

4. Delete the gateway itself.

   $ gcloud beta compute --project PROJECT target-vpn-gateways delete \
            --region us-central1 vpn1
   

Viewing Logs

To view logs for your tunnel from the {{ console_name_short}], do the following:

1. In the Developers Console, open your project.
2. Select Monitoring > Logs.
3. From the pulldown that says All resource types, select gateway.

Alternatively, get a direct URL from gcloud compute:

1. Determine the name of your tunnel:

   $ gcloud beta compute --project PROJECT vpn-tunnels list \
            --region us-central1
   

2. Get details on your tunnel:

   $ gcloud beta compute --project PROJECT vpn-tunnels describe \
            --region us-central1 tunnel1
   

3. From the following line in your output, copy the URL into your browser:

   detailedStatus: 'Tunnel is up and running. More info: https://console.developers.google.com/project/...
   

Logs Viewer has more information on using the viewer.

Troubleshooting

If you're having issues with your tunnel, start by checking your logs.

Check the following:

1. Verify that the peer IP configured on the Compute Engine VPN gateway is correct.
2. Check that traffic is flowing between the two VPN gateways in both directions. In the Compute Engine VPN logs, check for reported incoming messages from the Customer VPN gateway. Also, consider checking the Customer VPN gateway for messages from Compute Engine VPN gateway.
3. Check if the IKE version configured on the VPN gateways matches.
4. Check if there exists some firewall/NAT configured between the two VPN gateways that is modifying source IP information. This can prevent the gateways from connecting.
5. If the VPN logs indicate error no-proposal-chosen, this indicates that there was no match between the algorithms configured on the pair of VPN gateways. In IKEv1, the set of algorithms must be a complete match. In IKEv2, there must be one common algorithm between the two configurations. Make sure the Customer VPN gateway is configured to support the values listed in Configure your local device

Advanced Setup

Choosing the IP ranges for the networks using the VPN

The address ranges of your Compute Engine machines and those on your customer side VPN have to be distinct in order for the VPN to route the traffic successfully. Please make sure to choose addresses so as to avoid address collisions.

Redundancy and failover

If a Compute Engine VPN gateway or tunnel goes down, it restarts automatically. If an entire virtual device fails, Compute Engine automatically instantiates a new one with the same configuration. The new one connects automatically.

If your customer side is hardware based, you will likely want some kind of redundancy in your systems.

The steps to achieve this, are as follows: 1. Configure a second Customer VPN gateway and a tunnel. 2. Set up a second tunnel on the same Compute Engine VPN gateway pointing at the second Customer gateway. 3. Forward the same routes for the second tunnel as you did for the first. 4. If one VPN tunnel fails due to outage of Customer VPN gateway, the Google Compute Engine VPN gateway continues to use the other VPN tunnel, then automatically begin using both tunnels again once the failed one comes back up.

Recommended measures to increase VPN throughput

When measuring throughput in TCP streams, it is better to use more than one TCP stream. For instance, if you are measuring using the iperf tool, you should tune the -P parameter to add multiple streams.

VPN connectivity can be configured to achieve high throughput when the negotiated CHILD_SA is using an encryption and authentication algorithm called AES-GCM. This algorithm can be negotiated with the Compute Engine VPN gateway when using IKEv2. If your Customer VPN gateway supports IKEv2 and AES-GCM, it is recommend to use them to achieve the desired high throughput. However, if there are reasons not to use the recommended algorithm, other algorithms can be supported through the VPN gateway’s negotiation process.

It is important to understand the Customer VPN gateway’s throughput limitations and ensure appropriate throughput levels are supported by the Customer VPN gateway.

If your Customer VPN gateway’s throughput capabilities are higher, and you would like to scale higher throughput from Compute Engine VPN gateway, it is recommended to set up a second VPN gateway in Compute Engine (as in step 2 below). You can also combine these strategies (as in step 3 below).

Option 1: Configure to scale your Customer VPN gateway

Set up a second Customer VPN gateway device with a different public IP address. Create a second tunnel on your existing Compute Engine VPN gateway that forwards the same IP range, but pointing at the second customer gateway IP. Your Compute Engine VPN gateway automatically load balances between the configured tunnels. It can be setup to have multiple tunnels load balanced this way to increase the aggregate VPN connectivity throughput.

Option 2: Configure to scale the Compute Engine VPN gateway

Add a second Compute Engine VPN gateway on the same region similar to the existing VPN gateway. The second Compute Engine VPN gateway can have a tunnel that points to the same IP address of the Customer VPN gateway as the tunnel on the first gateway. Once configured, the network automatically load balances the traffic to Customer VPN gateway, between these VPN tunnels on the two different Compute Engine VPN gateway.

Option 3: Scale at both the Customer VPN gateway and the Compute Engine VPN gateway

Combine options 1 and 2 mentioned above to scale throughput. If you have two Customer VPN gateways and two Compute Engine VPN gateways, each Google Compute Engine VPN gateway can have a tunnel pointing at each Customer VPN gateway public IP, giving you four load balanced tunnels between the VPN gateway thereby potentially increasing 4x times the bandwidth.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies.