Google Cloud Classic VPN disconnects intermittently

Question

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

Answer 1

Was a solution ever found for this issue? I'm encountering a similar issue where a GCP VPN and a customer drops several days after initial connection. The only way i've found to get the VPN back online is to have the customer reset the connection on their end.

Logs at the approximate time the vpn dropped shows:

parsed CREATE_CHILD_SA request 51 [ SA No KE TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]

received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding

Warning: Local traffic selectors narrowed for Child SA: vpn_###.###.### Configured TS: [###.###.###/32], negotiated TS:[###.###.###/32[tcp/65001] ###.###.###/32 ]. Please verify configuration on the remote side.

Warning: Remote traffic selectors narrowed for Child SA: vpn_###.###.###.###. Configured TS: [###.###.###.###/32 ], negotiated TS:[###.###.###.###/32[tcp/60394] ###.###.###.###/32 ]. Please verify configuration on the remote side.

handling HA CHILD_SA vpn_###.###.###.###{4302} ###.###.###.###/32 === ###.###.###.###/32 (segment in: 1*, out: 1*)

generating CREATE_CHILD_SA response 51 [ SA No KE TSi TSr ]

Note: After the above messages are logged the next 5 messages repeat over and over until the vpn connection is reset on the customer side.

sending packet: from ###.###.###.###[500] to ###.###.###.###[500] (476 bytes)

sending DPD request

generating INFORMATIONAL_V1 request 3569313833 [ HASH N(DPD) ]

parsed INFORMATIONAL_V1 request 1654888155 [ HASH N(DPD_ACK) ]

sending packet: from ###.###.###.###[500] to ###.###.###.###[500] (92 bytes)

received packet: from ###.###.###.###[500] to ###.###.###.###[500] (92 bytes)

Editing to add: This issue has been in place for about 3 years until the client performed an update (firmware I believe) on their firewalls, The issue now occurs weekly and VPN will not reconnect without customer bouncing their end of the VPN.