Questions[google-cloud-vpn](server)

A couple of weeks back we have created google cloud classic VPN and created a tunnel with other on-premise network the connection was established successfully and we are able to access their application(s) but after a couple of hours, VPN started disconnects intermittently. I have observed establishing IKE_SA failed, peer not responding error in the logs.

When VPN goes down the VPN tunnel status was sometimes NO INCOMING PACKETS and sometimes FIRST HANDSHAKE. I don't know what is happening.

VPN configuration details:

1. Region: us-east1
2. Routing type: Policy-based
3. IKE version: IKEv2

Logs:

1.  creating acquire job for policy with reqid {1}
2.  initiating IKE_SA vpn_BB.BBB.BBB.BBB[21328] to BB.BBB.BBB.BBB
3.  generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
4.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
5.  retransmit 1 of request with message ID 0 
6.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
7.  retransmit 2 of request with message ID 0
8.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
9.  creating acquire job for policy with reqid {1}
10. ignoring acquire, connection attempt pending
11. retransmit 3 of request with message ID 0
12. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
13. retransmit 4 of request with message ID 0 
14. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
15. retransmit 5 of request with message ID 0 
16. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
17. creating acquire job for policy with reqid {1}
18. ignoring acquire, connection attempt pending
19. giving up after 5 retransmits
20. establishing IKE_SA failed, peer not responding

Can someone explain what's going on?

Please check the latest logs of my GCP VPN

1.  peer didn't accept DH group MODP_2048, it requested MODP_1024
2.  remote host is behind NAT
3.  authentication of 'AA.AAA.AAA.AAA' (myself) with pre-shared key
4.  establishing CHILD_SA vpn_ BB.BBB.BBB.BBB
5.  generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(EAP_ONLY) ]
6.  parsed IKE_AUTH response 1 [ IDr AUTH N(CRASH_DET) SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) N(ADD_TS_POSS) ]
7.  authentication of ' BB.BBB.BBB.BBB' with pre-shared key successful
8.  IKE_SA vpn_ BB.BBB.BBB.BBB [21588] established between AA.AAA.AAA.AAA [AA.AAA.AAA.AAA]... BB.BBB.BBB.BBB [BB.BBB.BBB.BBB]
9.  scheduling rekeying in 35937s
10. maximum IKE_SA lifetime 36537s
11. received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
12. Remote traffic selectors narrowed for Child SA: vpn_ BB.BBB.BBB.BBB. Configured TS: [XX.XXX.X.X/24 YYY.YY.YYY.Y/24 ], negotiated TS:[XX.XXX.X.X/24 ]. Please verify configuration on the remote side
13. handling HA CHILD_SA vpn_ BB.BBB.BBB.BBB{66} ZZ.ZZZ.Z.Z/24 === XX.XXX.X.X/24 (segment in: 1, out: 1)
14. CHILD_SA vpn_68.112.246.185{66} established with SPIs 07ab7fec_i de049161_o and TS ZZ.ZZZ.Z.Z/24 === XX.XXX.X.X/24
15. sending DPD request

we have a classic VPN setup for one of our customers. The tunnel is located in europe-west1. It was created on January and all went smooth until last week.

Since last week, we have been seeing a progressive degradation of the VPN connection. Looking at the logs, the cause seems a proposal mismatch in CHILD SA (phase 2), but it comes with no information about which parameter doesn't match.

According to the logs, the parameters check reports the following:

Cloud VPN has 1 proposals. Peer has 1 proposals.
Cloud VPN proposal #1 vs Peer proposal #1 :
Match parameters:
ENCRYPTION_ALGORITHM : ESP:AES_GCM_16_256
EXTENDED_SEQUENCE_NUMBERS : ESP:NO_EXT_SEQ
PFS : ESP:MODP_1024
Mismatch parameters:
<some empty lines>

Do you have any idea on how to figure out the problem? Thanks!

Please help!

My google cloud classic VPN to on prem network stopped working yesterday after a network outage.

The VPN is established on site on cisco asa but the pkt dcaps are 0. The tunnel is active.

The google log has warnings like this: "Warning: Local traffic selectors narrowed for Child SA: vpn_x.x.x.x. Configured TS: [0.0.0.0/0 ], negotiated TS:[10.210.3.8/32 10.210.0.0/16 ]. Please verify configuration on the remote side."

I have not changed any configuration on the asa or on gcp side. Can someone please help me on what might be going on here? I will really appreciate it.

Thanks, Ankit

Environment: Google Cloud w/ GSuite Requirement: Users on Windows/Linux/Android/iOS need to be able to VPN into VPC of a Google Project. Ideally integrate with the user accounts in GSuite (Cloud Identity)

GCloud: "Cloud VPN only supports site-to-site IPsec VPN connectivity, subject to the requirements listed in this section. It does not support client-to-gateway (road warrior) scenarios. In other words, Cloud VPN doesn't support use cases where client computers need to "dial in" to a VPN using client VPN software."

https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview#vpn-types

Therefore Cloud VPN does NOT appear to be a valid option.

Other Hyperscalers appear to address this need, but not Google.

Azure: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/aad.azurevpnclient AWS: https://aws.amazon.com/vpn/client-vpn-download/

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.