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.
Viewing logs and metrics
Checking error messages
- Go to the VPN page in the Google Cloud Console.
Go to the VPN page - 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 console.
Checking VPN logs
Cloud VPN logs are stored in Cloud Logging. Logging is automatic and does not need to be enabled.
For your peer 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 peer network between the hosts and the gateway, or there is a problem with the network between the peer gateway and the Cloud VPN gateway.
Check the logs for the following information:
- Verify that the remote peer IP address configured on the Cloud VPN gateway is correct.
- Verify that traffic flowing from your on-premises hosts is reaching the peer gateway.
- 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.
- Check that the IKE versions configured is the same on both sides of the tunnel.
- Check that the shared secret is the same on both sides of the tunnel.
- If your peer VPN gateway is behind one-to-one NAT, ensure that the NAT device has been properly configured to forward UDP traffic to your peer VPN gateway on ports 500 and 4500. Your peer gateway must be configured to identify itself using the external IP address of the NAT device. Refer to on-premises gateways behind NAT for details.
- If the VPN logs show a
no-proposal-chosenerror, this indicates that Cloud VPN and your peer 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 peer VPN gateway is configured using supported ciphers. - Check that your peer and Google Cloud routes and firewall rules are configured so that traffic can traverse the tunnel. You might need to contact your network administrator for help.
You can also search your logs for the following strings in order to find specific problems:
- Go to the Logs viewer in the Google Cloud Console.
Go to the Logs viewer - In the filter by label or text search box, click the disclosure triangle on the far right and choose Convert to Advanced Filter.
- Use one of the advanced filters listed below to search for a particular event, and adjust the time frame as necessary.
| To See | Use this Logging Search |
|---|---|
| Cloud VPN initiates Phase 1 (IKE SA) | resource.type="vpn_gateway"
("initiating IKE_SA" OR "generating IKE_SA_INIT request")
|
| Cloud VPN cannot contact remote peer | resource.type="vpn_gateway" "establishing IKE_SA failed, peer not responding" |
| IKE (Phase 1) authentication events | resource.type="vpn_gateway"
("generating IKE_AUTH request" OR "parsed IKE_AUTH response")
|
| Successful IKE authentication | resource.type="vpn_gateway"
("authentication of" AND "with pre-shared key successful") |
| Phase 1 (IKE SA) established | resource.type="vpn_gateway"
("IKE_SA" AND "established between")
|
| All Phase 2 (Child SA) events, including re-key events | resource.type="vpn_gateway" "CHILD_SA" |
| Peer asks for Phase 2 re-key | resource.type="vpn_gateway" detected rekeying of CHILD_SA |
| Peer asks to terminate Phase 2 (Child SA) | resource.type="vpn_gateway" received DELETE for ESP CHILD_SA |
| Cloud VPN asks to terminate Phase 2 (Child SA) | resource.type="vpn_gateway" sending DELETE for ESP CHILD_SA |
| Cloud VPN closes Phase 2 (Child SA), perhaps in response to the peer | resource.type="vpn_gateway" closing CHILD_SA |
| Cloud VPN closed Phase 2 itself | resource.type="vpn_gateway" CHILD_SA closed |
| If remote traffic selectors don't match | resource.type="vpn_gateway" Remote traffic selectors narrowed |
| If local traffic selectors don't match | resource.type="vpn_gateway" Local traffic selectors narrowed |
Checking connectivity
Consider the following suggestions when verifying connectivity between on-premises systems and Google Cloud VMs using ping:
Ensure the firewall rules in your Google Cloud 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 Google Cloud 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 Google Cloud, 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.
Calculating network throughput
You can calculate network throughput within Google Cloud and to your on-premises or third-party cloud locations. The above document includes information on how to analyze results, explanations of variables that can affect network performance, and troubleshooting tips.
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 peer 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 peer 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 Logging 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 external 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 external 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
Google Cloud VMs, and you've verified that both Google Cloud 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 Classic VPN tunnel using policy based routing or a route based VPN. You also specify traffic selectors when you create the corresponding peer 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 Classic VPN tunnel, you must delete and re-create the tunnel. These steps are 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 peer network.
- The local traffic selector for your peer 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 peer VPN gateway.
- The Cloud VPN remote traffic selector should match the local traffic selector for the tunnel on your peer VPN gateway.
Connecting Classic VPN and HA VPN gateways
Google Cloud does not support creating a tunnel from a
HA VPN gateway that connects to a
Classic VPN gateway. If you attempt to create an
externalVpnGateway resource having the external IP address of a
Classic VPN gateway, Google Cloud returns the following
error message:
You cannot provide an interface with an IP address owned by Google Cloud. You can only create tunnels from an HA gateway to an HA gateway or create tunnels from an HA gateway to an ExternalVpnGateway.
This is expected behavior. Create a VPN tunnel that connects a HA VPN gateway to another HA VPN gateway instead.
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 console:
| Icon graphic | Color | Description | Applies to messages |
|
Green | Success | ESTABLISHED |
|
Yellow | Warning | ALLOCATING RESOURCES, FIRST HANDSHAKE, WAITING FOR FULL CONFIG, PROVISIONING |
|
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 being added to a denylist | 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 cipher overview
The following IKE ciphers are supported for Classic VPN and HA VPN.
There are two sections for IKEv2, one for ciphers using authenticated encryption with associated data (AEAD), and one for ciphers that do not use AEAD.
IKEv2 ciphers that use AEAD
Phase 1
| Cipher role | Cipher | Notes |
|---|---|---|
| Encryption & Integrity |
|
In this list, the first number is the size of the ICV parameter
in bytes (octets) and the second is the key length in bits. Some documentation might express the ICV parameter (the first number) in bits instead (8 becomes 64, 12 becomes 96, and 16 becomes 128). |
| Pseudo-Random Function (PRF) |
|
Many devices won't require an explicit PRF setting. |
| Diffie-Hellman (DH) |
|
Cloud VPN's proposal presents these key exchange algorithms in the order shown. Cloud VPN accepts any proposal that includes one or more of these algorithms in any order. |
| Phase 1 lifetime | 36,000 seconds (10 hours) | — |
Phase 2
| Cipher role | Cipher | Notes |
|---|---|---|
| Encryption & Integrity |
|
Cloud VPN's proposal presents these algorithms in the order shown.
Cloud VPN accepts any proposal that includes one or more of these
algorithms, in any order. Note that the first number in each algorithm is the size of the ICV parameter in bytes (octets) and the second is its key length in bits. Some documentation might express the ICV parameter (the first number) in bits instead (8 becomes 64, 12 becomes 96, 16 becomes 128). |
| PFS Algorithm (required) |
|
Cloud VPN's proposal presents these key exchange algorithms in the order shown. Cloud VPN accepts any proposal that has one or more of these algorithms in any order. |
| Diffie-Hellman (DH) | Refer to Phase 1 | If your VPN gateway requires DH settings for Phase 2, use the same settings you used for Phase 1. |
| Phase 2 lifetime | 10,800 seconds (3 hours) | — |
IKEv2 ciphers that don't use AEAD
Phase 1
| Cipher role | Cipher | Notes |
|---|---|---|
| Encryption |
|
Cloud VPN's proposal presents these symmetric encryption algorithms in the order shown. Cloud VPN accepts any proposal that use one or more of these algorithms, in any order. |
| Integrity |
|
Cloud VPN's proposal presents these HMAC algorithms
in the order shown. Cloud VPN accepts any proposal that has one
or more of these algorithms, in any order. Documentation for your on-premises VPN gateway might use a slightly different name for the algorithm. For example, HMAC-SHA2-512-256 might
be referred to as just SHA2-512 or SHA-512, dropping the
truncation length number and other extraneous information.
|
| Pseudo-Random Function (PRF) |
|
Many devices won't require an explicit PRF setting. |
| Diffie-Hellman (DH) |
|
Cloud VPN's proposal presents these key exchange algorithms in the order shown. Cloud VPN accepts any proposal that contains one or more of these algorithms, in any order. |
| Phase 1 lifetime | 36,000 seconds (10 hours) | — |
Phase 2
| Cipher role | Cipher | Notes |
|---|---|---|
| Encryption |
|
Cloud VPN's proposal presents these symmetric encryption algorithms in the order shown. Cloud VPN accepts any proposal that contains one or more of these algorithms, in any order. |
| Integrity |
|
Cloud VPN's proposal presents these
HMAC algorithms in the order shown. Cloud VPN accepts
any proposal that contains one or more of these algorithms, in any order. Documentation for your on-premises VPN gateway might use a slightly different name for the algorithm. For example, HMAC-SHA2-512-256 might be referred to as just SHA2-512 or
SHA-512, dropping the truncation length number and other extraneous information.
|
| PFS Algorithm (required) |
|
Cloud VPN's proposal presents these key exchange algorithms in the order shown. Cloud VPN accepts any proposal that contains one or more of these algorithms, in any order. |
| Diffie-Hellman (DH) | Refer to Phase 1. | If your VPN gateway requires DH settings for Phase 2, use the same settings that you used for Phase 1. |
| Phase 2 lifetime | 10,800 seconds (3 hours) | — |
IKEv1 ciphers
Phase 1
| Cipher role | Cipher |
|---|---|
| Encryption | AES-CBC-128 |
| Integrity | HMAC-SHA1-96 |
| Pseudo-Random Function (PRF)* | PRF-SHA1-96 |
| Diffie-Hellman (DH) | modp_1024 (Group 2) |
| Phase 1 lifetime | 36,600 seconds (10 hours, 10 minutes) |
*For more information about PRF in IKEv1, see RFC 2409.
Phase 2
| Cipher role | Cipher |
|---|---|
| Encryption | AES-CBC-128 |
| Integrity | HMAC-SHA1-96 |
| PFS Algorithm (required) | modp_1024 (Group 2) |
| Diffie-Hellman (DH) | If you need to specify DH for your VPN gateway, use the same setting that you used for 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
- Learn about the basic concepts of Cloud VPN.
- See Advanced Configurations for information on high-availability, high-throughput scenarios, or multiple subnet scenarios.
- Create a custom Virtual Private Cloud network.
- Maintain VPN tunnels and gateways.