IKEV1 VPN with AWS Peer (Non VTI) - Incoming traffic stop working randomly after P2 renegotation

[bryanastudillo]

We have a VPN set up against AWS. Normally in this VPN the traffic is bidirectional, but we have noticed that randomly the traffic that is originated from the peer does not arrive or stops passing through the VPN after a P2 renegotiation and begins to arrive when the P2 is renegotiated again. In other words, if P2 was renegotiated at 1:30 p.m., the 3600 second timer expires, and it is regenerated at 2:30 p.m., here it starts working again.

When the traffic stops passing, in our firewall we see these logs:

Log1:

Id: 0abf0bd2-1dcc-2726-64f8-ca1ecb4a022c
Marker: @A@@B@1694024864@C@11152905
Log Server Origin: 10.191.11.210
Time: 2023-09-06T18:51:10Z
Interface Direction: inbound
Interface Name: daemon
Id Generated By Indexer:false
First: true
Sequence number: 225
Source: 34.195.30.101
IP Protocol: 0
Destination Port: 0
Encryption Failure: Unknown SPI: 0x5a4211c for IPsec packet.
VPN Peer Gateway: 34.195.30.101
Scheme: IKE
VPN Feature: IKE
Action: Drop
Type: Log
Blade:VPN
Origin: FW_GPRS_DURAN
Service: 0/0
Access Rule Number: 0
Interface: daemon
Description:

Log2:

Id: 0abf0bd2-1d4c-2726-64f8-ca78a54f004c
Marker: @A@@B@1694024864@C@11863241
Log Server Origin: 10.191.11.210
Time: 2023-09-06T18:52:40Z
Interface Direction: inbound
Interface Name: bond10.644
Id Generated By Indexer:false
First: true
Sequence number: 43
LogID: 404840
Source: 34.195.30.101
Destination: 190.111.65.126
IP Protocol: 50
Encryption Fail Reason: Packet is dropped because an IPsec SA associated with the SPI on the received IPsec packet could not be found
Member ID: 1_11
Action: Drop
Type: Connection
Policy Name: ClusterGPRSDuran_Ckp
Policy Management: Manager64k
DB Tag: {848FD104-DE25-9944-BC90-38D724932081}
Policy Date: 2023-09-05T20:22:13Z
Blade: Firewall
Origin: FW_GPRS_DURAN
Service: 50
Product Family: Access
Logid: 1
Interface: bond10.644
Description: ESP Traffic Dropped from 34.195.30.101 to 190.111.65.126

The strange thing is that if I go to see the SPIs with the VPN TU command, the gateway does have them registered.

Our enviroment is 64000 chassis R81.10 JHF take 109.

L4 distribution mode enabled.

I attached the evidence here.

[the_rock]

When did this start happening?

Andy

[bryanastudillo]

Good question. The problem started exactly after I upgraded the chassis from R80.20SP to R81.10 JHF take 109.

[the_rock]

Can you send output of below from CP?

vpn tu tlist -p peer_ip (just replace peer_ip with aws IP address)

Btw, does anything change if you reset the tunnel on both ends?

Andy

[bryanastudillo]

The output of that command during the failure is attached here in this post, it is called "vpn your tlist".

If the VPN is restarted from either end it starts working again.

[the_rock]

Right, sorry, my bad. In that case, I would open TAC case and see what they say. Personally, easy debug you can do yourself.

Andy

vpn debug trunc

vpn debug ikeon

-generate some traffic

vpn debug ikeoff

Get ike.elg and vpnd.elg from $FWDIRlog dir 

Andy

[bryanastudillo]

I ALREADY have a case open but I still don't have an answer. In the debugs it practically says the same as the logs.

messages like that:

W_GPRS_DURAN-ch01-11[5 Sep 15:31:04][tunnel] RequestBySPI: no match for spi b5b53723, owner 7f000001, peer 101.30.195.34 - will send Delete PL

[the_rock]

I dug through my old notes way back when I was helping someone with this, probably back from R65 days (I know, I know, there was no aws then haha), BUT...it was between CP and Cisco, literally same issue and we fixed it by enabling option to "keep all connections" under connections persistence on gateway properties and also "keep ike SAs" under global properties (advanced at the bottom and then vpn somewhere).

I dont have access to smart console right now, but can log in if you want me to find options Im referring to. Just watching "Jeopardy", nothing too exciting lol

Andy

[bryanastudillo]

Keep ike sas is already activated, I will check the other option. Thanks for your help.

[the_rock]

Will log in and send a screenshot, give me 5 mins.

Andy

[the_rock]

 

[bryanastudillo]

I already have this option enable. I have noticed that the initiator of the negotiations is always AWS. I have lowered the phase 2 timer on my side from 1 hour to 45 minutes, so far it has negotiated twice and now the Check Point side is starting renegotiations.

[the_rock]

Thats one option in case like this. I checked an official SK for tunnel config to aws and shows phase 1 420 mins and phase 2 3600 seconds.

Andy

[the_rock]

Sorry, 480 mins

https://support.checkpoint.com/results/sk/sk100726

[Matlu]

Hello.

Do these commands work for both IKEv1 and IKEv2?

In IKEv2, it is the same file to extract, for review?

Regards

[the_rock]

Yes bro, its the same.