Troubleshooting

This troubleshooting guide can help you monitor and solve common issues with Cloud VPN.

To interpret status messages and IKE cipher references, see the Reference section.

Monitoring VPN tunnels

Use Stackdriver Monitoring to view metrics and create alerts related to your VPN tunnels.

In addition to using Stackdriver Monitoring, you can view metrics by clicking the Monitoring tab for a tunnel in the Google Cloud Platform Console UI.

Checking error messages

  1. Go to the VPN page in the Google Cloud Platform Console.
    Go to the VPN page
  2. If you see an icon, hover over it to see the error message.

In many cases, the error message can help you pinpoint the issue. If not, check your logs for more information. There is also detailed status information on the Tunnel Details page in the Google Cloud Platform console.

Checking VPN logs

Cloud VPN logs are stored in Stackdriver Logging. Logging is automatic and does not need to be enabled.

For your on-premises gateway, view your product documentation for information about viewing logs for that side of the connection.

In many cases, the gateways are configured correctly, but there's a problem in the on-premises network between the hosts and the gateway, or there is a problem with the network between the on-premises gateway and the Cloud VPN gateway.

Check the logs for the following information:

  1. Verify that the on-premises IP configured on the Cloud VPN gateway is correct.
  2. Verify that traffic flowing from your on-premises hosts is reaching the on-premises gateway.
  3. Verify that traffic is flowing between the two VPN gateways in both directions. In the VPN logs, check for reported incoming messages from the other VPN gateway.
  4. Check that the IKE versions configured is the same on both sides of the tunnel.
  5. Check that the shared secret is the same on both sides of the tunnel.
  6. If your on-premises VPN gateway is behind one-to-one NAT, ensure that the NAT device has been properly configured to forward UDP traffic to your on-premises VPN gateway on ports 500 and 4500. Your on-premises gateway must be configured to identify itself using the public IP address of the NAT device. Refer to on-premises gateways behind NAT for details.
  7. If the VPN logs show a no-proposal-chosen error, this indicates that Cloud VPN and your on-premises VPN gateway were unable to agree on a set of ciphers. For IKEv1, the set of ciphers must match exactly. For IKEv2, there must be at least one common cipher proposed by each gateway. Make sure your on-premises VPN gateway is configured using supported ciphers.

If traffic still isn't arriving at its destination, check that your on-premises and Google Cloud Platform routes and firewall rules are configured so that traffic can traverse the tunnel. You might need to contact your network administrator for help.

Checking connectivity

Consider the following suggestions when verifying connectivity between on-premises systems and GCP VMs using ping:

  • Ensure the firewall rules in your GCP network allow incoming ICMP traffic. The implied allow egress rule permits outgoing ICMP traffic from your network unless you have overridden it. Similarly, make sure that your on-premises firewalls are also configured to allow incoming and outgoing ICMP traffic.

  • Ping GCP VMs and on-premises systems using their internal IP addresses. Pinging external IP addresses of VPN gateways does not test connectivity through the tunnel.

  • When testing connectivity from on-premises to GCP, it's best to initiate a ping from a system on your network, not from your VPN gateway. Pinging from a gateway is possible if you set the appropriate source interface, but pinging from an instance on your network has the added benefit of testing your firewall configuration.

  • Ping tests do not verify that TCP or UDP ports are actually open. You should perform additional tests once you have established that systems have basic connectivity by using ping.

Common problems and solutions

Tunnel regularly goes down for a few seconds

By default, Cloud VPN negotiates a replacement SA before the existing one expires (also known as rekeying). Your on-premises VPN gateway might not be rekeying. Instead, it might negotiate a new SA only after deleting the existing SA, causing interruptions.

To check whether your on-premises gateway rekeys, view the Cloud VPN logs. If the connection drops and then re-establishes right after a Received SA_DELETE log message, your on-premises gateway didn't rekey.

Verify tunnel settings using the Supported IKE Ciphers document. In particular, make sure that the Phase 2 lifetime is correct, and that a Diffie-Hellman (DH) group is set to one of the recommeded values.

You can use a Stackdriver advanced log filter to search for events in your Cloud VPN tunnel. For example, the following advanced filter will search for DH group mismatches:

resource.type="vpn_gateway"
"Peer proposal: DOES NOT HAVE DIFFIE_HELLMAN_GROUP"

On-premises gateways behind NAT

Cloud VPN can work with on-premises or peer VPN gateways that are behind NAT. This is made possible by UDP encapsulation and NAT-T, and only one-to-one NAT is supported.

As part of the authentication process, Cloud VPN checks the identity of the peer gateway. Cloud VPN expects every peer gateway to identify itself using the ID_IPV4_ADDR identity type as specified in RFC 7815 with the public IP (peer gateway) address configured for the Cloud VPN tunnel.

The following log messages indicate that the peer VPN gateway is incorrectly identifying itself with a private IP address. In this example, [PEER GATEWAY PRIVATE IP] is a private IP address, and [PEER GATEWAY PUBLIC IP] is the public IP address of the NAT device between the peer VPN gateway and the Internet.

authentication of '[PEER GATEWAY PRIVATE IP]' with pre-shared key successful
constraint check failed: identity '[PEER GATEWAY PUBLIC IP]' required
selected peer config 'vpn_[PEER GATEWAY PUBLIC IP]' inacceptable: constraint checking failed

When using one-to-one NAT, your on-premises VPN gateway must identify itself using the same public IP address of the NAT device:

  • The identity type must be ID_IPV4_ADDR (RFC 7815).

  • Not all Cisco devices support setting a device identity to an IP address different from the one the device is using (its internal address). For example, Cisco ASA devices do not support assignment of different (external) IP addresses for their identities. Thus, Cisco ASA devices cannot be configured to use one-to-one NAT with Cloud VPN.

  • For Juniper devices, you can set the identity of the device using set security ike gateway [NAME] local-identity inet [PUBLIC_IP] where [NAME] is your VPN gateway name and [PUBLIC_IP] is your public IP address. Refer to this Juniper TechLibrary article for more detail.

Connectivity works for some VMs, but not for others

If ping, traceroute, or other methods of sending traffic work from only some VMs to your on-premises systems, or from only some on-premises systems to some GCP VMs, and you've verified that both GCP and on-premises firewall rules are not blocking the traffic you are sending, you might have traffic selectors that exclude certain sources or destinations.

Traffic selectors define the ranges of IP addresses for a VPN tunnel. In addition to routes, most VPN implementations only pass packets through a tunnel if their sources fit within the IP ranges specified in the local traffic selector and if their destinations fit within the IP ranges specified in the remote traffic selector. You specify traffic selectors when you create a Cloud VPN tunnel using policy based routing or a route based VPN. You also specify traffic selectors when you create the corresponding on-premises tunnel.

Some vendors use terms like local proxy, local encryption domain, or left side network as synonyms for local traffic selector. Similarly, remote proxy, remote encryption domain, or right side network are synonyms for remote traffic selector.

To change traffic selectors for a Cloud VPN tunnel, you must delete and re-create the tunnel. This is required because the traffic selectors are an integral part of tunnel creation, and tunnels cannot be edited later.

Use the following guidelines when defining traffic selectors:

  • The local traffic selector for the Cloud VPN tunnel should cover all subnets in your VPC network that you need to share with your on-premises network.
  • The local traffic selector for your on-premises network should cover all on-premises subnets you need to share with your VPC network.
  • For a given VPN tunnel, traffic selectors have the following relationship:
    • The Cloud VPN local traffic selector should match the remote traffic selector for the tunnel on your on-premises VPN gateway.
    • The Cloud VPN remote traffic selector should match the local traffic selector for the tunnel on your on-premises VPN gateway.

Troubleshooting reference

This section includes a list of status icons, status messages, and a list of supported IKE ciphers.

Status icons

Cloud VPN uses the following status icons in the Google Cloud Platform console:

Icon graphic Color Description Applies to messages
Green success icon
Green Success ESTABLISHED
Yellow warning icon
Yellow Warning ALLOCATING RESOURCES, FIRST HANDSHAKE, WAITING FOR FULL CONFIG, PROVISIONING
Red error icon
Red Error All remaining messages

Status messages

Cloud VPN uses the following status messages to indicate VPN gateway and tunnel states. The VPN tunnel is billed for the states indicated.

Message Description Tunnel billed in this state?
ALLOCATING RESOURCES Allocating resources to set up the tunnel Yes
PROVISIONING Waiting to receive all configs to set up the tunnel No
WAITING FOR FULL CONFIG Full config received, but a tunnel is not yet established Yes
FIRST HANDSHAKE Establishing the tunnel Yes
ESTABLISHED A secure communication session is successfully established Yes
NETWORK ERROR
(replaced by NO INCOMING PACKETS)
Bad IPsec authorization Yes
AUTHORIZATION ERROR Handshake failed Yes
NEGOTIATION FAILURE The tunnel configuration was rejected, can be due to blacklisting Yes
DEPROVISIONING The tunnel is being shutdown No
NO INCOMING PACKETS The gateway is not receiving any packets from the on-premises VPN Yes
REJECTED The tunnel configuration was rejected, please contact Support. Yes
STOPPED The tunnel is stopped and not active. This can be due to the deletion of one or more required forwarding rules for the VPN tunnel. Yes

IKE Ciphers

For each role, the most secure option presently supported in Cloud VPN is bolded
Note: Cloud VPN operates in IPSec ESP Tunnel Mode

IKEv2 supported ciphers
Phase Cipher role Cipher
Phase 1 Encryption • 3DES
• AES-CBC-128, AES-CBC-192, AES-CBC-256
• AES-GCM-128-8, AES-GCM-192-8, AES-GCM-256-8
• AES-GCM-128-12, AES-GCM-192-12, AES-GCM-256-12
• AES-GCM-128-16, AES-GCM-192-16, AES-GCM-256-16
On some platforms, GCM algorithms may have their ICV parameter octets (8, 12, 16) specified in bits (64, 96, 128 respectively).
Integrity • HMAC-MD5-96
• HMAC-SHA1-96
• AES-XCBC-96, AES-CMAC-96
• HMAC-SHA2-256-128, HMAC-SHA2-384-192, HMAC-SHA2-512-256
These names vary depending on platform. For example, HMAC-SHA2-512-256 may be referred to as just SHA-512, dropping the truncation length number and other extraneous information.
Pseudo-Random Function (PRF) • PRF-MD5-96
• PRF-SHA1-96
• PRF-AES-XCBC-96, PRF-AES-CMAC-96
• PRF-SHA2-256, PRF-SHA2-384, PRF-SHA2-512
Many devices won't require an explicit PRF setting.
Diffie-Hellman (DH) • Group 2 (modp_1024), Group 5 (modp_1536), Group 14 (modp_2048), Group 15 (modp_3072), Group 16 (modp_4096)
• modp_1024s160, modp_2048s224, modp_2048s256
Phase 1 lifetime 36,000 seconds (10 hours)
Phase 2 Encryption • 3DES
• AES-CBC-128, AES-CBC-192, AES-CBC-256
• AES-GCM-128-8, AES-GCM-192-8, AES-GCM-256-8
• AES-GCM-128-12, AES-GCM-192-12, AES-GCM-256-12
• AES-GCM-128-16, AES-GCM-192-16, AES-GCM-256-16
On some platforms, GCM algorithms may have their ICV parameter octets (8, 12, 16) specified in bits (64, 96, 128 respectively).
Integrity • HMAC-MD5-96
• HMAC-SHA1-96
• AES-XCBC-96, AES-CMAC-96
• HMAC-SHA2-256-128, HMAC-SHA2-384-192, HMAC-SHA2-512-256
These names vary depending on platform. For example, HMAC-SHA2-512-256 may be referred to as just SHA-512, dropping the truncation length number and other extraneous information.
PFS Algorithm (required) • Group 2 (modp_1024), Group 5 (modp_1536), Group 14 (modp_2048), Group 15 (modp_3072), Group 16 (modp_4096), Group 18 (modp_8192)
• modp_1024s160, modp_2048s224, modp_2048s256
Diffie-Hellman (DH) Some devices require a DH value for Phase 2. If so, use the value that you used in Phase 1.
Phase 2 lifetime 10,800 seconds (3 hours)
IKEv1 supported ciphers
Phase Cipher Role Cipher
Phase 1 Encryption AES-CBC-128
Integrity HMAC-SHA1-96
PFS Algorithm (required) Group 2 (modp_1024)
Pseudo-Random Function (PRF) PRF-SHA1-96
Diffie-Hellman (DH) Group 2 (modp_1024)
Phase 1 lifetime 36,600 seconds (10 hours, 10 minutes)
Phase 2 Encryption AES-CBC-128
Integrity HMAC-SHA1-96
Diffie-Hellman (DH) Some devices require a DH value for Phase 2. If so, use the value that you used in Phase 1.
Phase 2 lifetime 10,800 seconds (3 hours)

What's next

Troubleshooting related

  • Refer to the Logging documentation for more information, including how to export logs and how to use logs-based metrics for monitoring and alerting.

VPN related

Was this page helpful? Let us know how we did:

Send feedback about...