Home / server / Questions / 1027127
Accepted
Tsukasa Naritomi
Asked: 2020-07-29 14:43:35 +0800 CST

still vpn description "Allocating resources. VPN tunnel will start soon."

  • 772

From local linux , I tried check vpn status.

Why detailedStatus not proceed ? Why status still "FIRST_HANDSHAKE" ?

Shared key and TargetIP was not wrong.

$ gcloud compute vpn-tunnels describe gvis-vpn-tunnel

And echo was here.

 creationTimestamp: '2020-07-28T15:05:44.541-07:00'

 description: ''

 detailedStatus: Allocating resources. VPN tunnel will start soon.

 id:'2892217179569987543'

 ikeVersion: 2

 kind: compute#vpnTunnel
 
 :

 region: https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-east1

 : 

 sharedSecret: '*************'

 : 

 status: FIRST_HANDSHAKE

 targetVpnGateway: https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-east1/targetVpnGateways/gvis-vpn

UPDATE

Last week , I could connect vpn tunnel. From this monday, could not connect and I saw logging as follows:

2020-07-28T22:45:04.831987016Z  initiating IKE_SA vpn_58.xxx.xxx.xxx[779] to 58.xxx.xxx.xxx
2020-07-28T22:45:04.758749637Z  creating acquire job for policy with reqid {1}
2020-07-28T22:45:02.148478373Z  sending packet: from 35.xxx.xxx.xxx[4500] to 58.xxx.xxx.xxx[4500] (80 bytes)
2020-07-28T22:45:02.148478373Z  generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
2020-07-28T22:45:02.148478373Z  tried 1 shared key for '35.xxx.xxx.xxx' - '58.xxx.xxx.xxx', but MAC mismatched
2020-07-28T22:45:02.148478373Z  parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
2020-07-28T22:45:02.105535147Z  received packet: from 58.xxx.xxx.xxx[4500] to 35.xxx.xxx.xxx[4500] (256 bytes)
2020-07-28T22:45:02.029020541Z  sending packet: from 35.xxx.xxx.xxx[4500] to 58.xxx.xxx.xxx[4500] (336 bytes)
2020-07-28T22:45:02.029020541Z  generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ]
2020-07-28T22:45:02.029020541Z  establishing CHILD_SA vpn_58.xxx.xxx.xxx{1}
2020-07-28T22:45:02.029020541Z  authentication of '35.xxx.xxx.xxx' (myself) with pre-shared key
2020-07-28T22:45:02.029020541Z  remote host is behind NAT
2020-07-28T22:45:02.029020541Z  parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
2020-07-28T22:45:01.933846400Z  received packet: from 58.xxx.xxx.xxx[500] to 35.xxx.xxx.xxx[500] (464 bytes)
2020-07-28T22:45:01.819625244Z  sending packet: from 35.xxx.xxx.xxx[500] to 58.xxx.xxx.xxx[500] (892 bytes)
2020-07-28T22:45:01.819625244Z  generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]

Pre-shared key is same since December 2019. Everyday, When I want to connect , made vpn-tunnel like this,

 gcloud compute vpn-tunnels create [my-vpn-tunnel] \
     --peer-address 58.xxx.xxx.xxx \
     --ike-version 2 \
     --shared-secret [Pre-shared key] \
     --local-traffic-selector=192.xxx.100.0/24 \
     --remote-traffic-selector=172.xx.xx.0/24,192.xxx.10.0/24 \
     --target-vpn-gateway [my-vpn] \
     --region us-east1 \
     --project [project-id]

And When I disconnect, delete vpn-tunnel like this,

gcloud compute vpn-tunnels delete [my-vpn-tunnel] --region=us-east1

I've always use gcloud on my linux shell script.

vpn google-cloud-platform google-cloud-vpn

1 Answers

  1. Best Answer

    Because your problem resolved on its own we can only guess what caused this issue before.

    As I wrote in the comments, it's better to follow troubleshooting guide and start from Cloud VPN logs.

    2020-07-28T22:45:02.148478373Z  tried 1 shared key for '35.xxx.xxx.xxx' - '58.xxx.xxx.xxx', but MAC mismatched

    Message Authentication Codes (MACs) are computed based on the pre shared key and the message and if pre shared keys do not match, corresponding MACs will not match as well. Meanwhile, it doesn't look like your case because you claim that "pre-shared key is same since December 2019".

    2020-07-28T22:45:02.029020541Z  remote host is behind NAT

    Because you use NAT, I'd recommend you to have a look at the troubleshooting guide section 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.

    more details you can find in this section:

    Cloud VPN only supports one-to-one NAT via UDP encapsulation for NAT-Traversal (NAT-T). One-to-many NAT and port-based address translation are not supported. In other words, Cloud VPN cannot connect to multiple peer VPN gateways that share a single external IP address.

    When using one-to-one NAT, a peer VPN gateway must be configured to identify itself using an external IP address, not its internal (private) address. When you configure a Cloud VPN tunnel to connect to a peer VPN gateway, you specify an external IP address. Cloud VPN expects an on-premises VPN gateway to use its external IP address for its identity.

    It's possible that this issue could be related to your on-premises router, but it's hard to say without any logs.

    In addition, next time you can check if this issue on the Google's side at the Google Cloud Status Dashboard and file an issue report at the Google Issue Tracker.

    • 0