IPSec VPN Tunnel stops passing traffic after exactly 1 hour

[johnnyringo]

I've successfully built a route-based tunnel between a Cisco ISRG2 and CheckPoint R80.30 gateway in GCP.  Both sides are using IKEv1 with the default lifetimes of 1 day for Phase 1 and 1 hour for Phase 2.

Unfortunately, the tunnel stops passing traffic after it's been up for an hour.  Here's the relevant IPSec configuration on the Cisco (the default lifetime is 3600 seconds, so it doesn't show up in the configuration):

crypto ipsec transform-set ESP_AES128_SHA esp-aes esp-sha-hmac
  mode tunnel

crypto ipsec profile CHECKPOINT_IKEV1
  set security-association lifetime kilobytes disable
  set transform-set ESP_AES128_SHA

[Blason_R]

Not sure with GCP but with AWS there is sk for such behaviour 

Try sk113561

[johnnyringo]

To be clear, I'm talking about a CheckPoint CloudGuard IaaS R80.30 gateway inside GCP.  This has nothing to do with GCP-native tunnels.  

Just did some packet captures and it appears the problem is when initiating a tunnel or refreshing the SA, the CheckPoint incorrectly sends the public IP address as the source interface.   Almost like NAT-T is broken when the CheckPoint is initiator mode.

[firewall1-gx]

Hi Johnny,

Probably you are facing this issue during IKE SAs renegotiation. I suggested to enable keep_IKE_SAs or to configure a keep alive traffic inside IPsec tunnel to maintain always alive.

To enable keep_IKE_SAs option, follow: In Global Properties, click 'SmartDashboard Customization', and then click 'Configure'. Once on the 'Configure' window, expand 'VPN Advanced Properties' and click on 'VPN IKE properties'. Select 'keep_IKE_SAs' and click OK.

Regards,

Alisson Lima

[johnnyringo]

Yeah so I already tried a few things which helped, but hasn't completely solved the problem:

• Enabled PFS at Phase 2 / IPSec
• Enabled keep_IKE_SAs and ike_send_initial_contact  
• Enabled DPD

Spent a couple hours troubleshooting this with support this morning and it really looks like a NAT-T issue.  When the remote end initiates or freshes, the SAs come up on udp/4500 and everything is hunky-dory.  When the CheckPoint initiates, the SAs come up at udp/500 and traffic gets sent over the tunnel but never received.  

[Timothy_Hall]

Yes this NAT-T issue with Cisco has been discussed before, see here:

https://community.checkpoint.com/t5/General-Topics/VPN-issue-with-IKEv2-and-Cisco-ASA/m-p/64830

[johnnyringo]

This is for a Cisco router (not ASA).   I also see it on Palo Altos, and even on a Fortigate that's not behind NAT.  

I realized there's two things going on.  First, when acting as initiator, the CheckPoint does not negotiate NAT-T.  Since we did not have esp allowed in our firewall rules, this would result in the tunnel coming up (udp/500 OK) but not passing ESP traffic which is required for the payload.  Adding esp to the GCP firewall rule mostly fixed the issue. 

There's still a edge case still being problematic: remote end is behind NAT.  If using IKEv1, tunnel comes up fine on udp/4500, but with IKEv2 the tunnel won't come up at all.  I have a case open with TAC on this.