VPN is going down

[Jesus_Cano]

Hi,

We Just configured a VPN between Checkpoint R80.10 and Fortigate. The VPN is up and traffic is flowing. The issue is that sometime the tunnel stop processing traffic and we need to renew in order to work again. So why the tunnel goes down? its because inactivity? 

[Matt_Killeen]

This is diffcult to diagnose without seeing the full VPN configuration of both the CheckPoint and Fortigate.

Checkpoint uses DPD and I believe Fortigate uses Auto Keep Alive so, even if these are configured and working, dropping the tunnel due to inactivity may not be the problem.

Before you go to deep into troubleshooting, however, one thing I would ask you to check is the LifeTimes on the CheckPoint side for Phase I and Phase II match the Fortigate side and that on the Fortigate side, the Phase II KeyLife is set to Seconds and not "KiloBytes" or "Both" . If the Fortigate is using KiloBytes as the key life time, it could try to create new keys before the CheckPoint is ready. This makes the re-key unpredictable as it's dependent on how much data has been processed in any given time period.

If one side tries to regenerate keys before the other side is ready you will have problems with the tunnel.

[Jesus_Cano]

Where its configured DPD in R80.10, i can not find this config.

[Matt_Killeen]

Sorry - I'm calling it DPD out of old habits. It's Permanent Tunnels in Tunnel Management.

[Jesus_Cano]

OK, but i read that permanent tunnels is only working between Checkpoint appliances. In this case one is CPK and the peer is fortigate.

[Matt_Killeen]

So if Permanent Tunnels are not configured on the CheckPoint (and you've not configured DPD Responder Mode for permanent tunnels to 3rd party) and if Auto Keep Alive is not configured on the Fortigate, the tunnel should drop due to inactivity and re-establish when interesting traffic is processed.

[Jesus_Cano]

The issue is that the tunnel goes down but even with interesting traffic is not coming up. WE need to renegotiate the tunnel in order to go up again.

[Matt_Killeen]

So, have you checked the LifeTimes on the CheckPoint side for Phase I and Phase II match the Fortigate side and that on the Fortigate side, the Phase II KeyLife is set to Seconds and not "KiloBytes" or "Both" ?

[Jesus_Cano]

This is CPK config. I will ask the config in the peer (fortigate).

[Timothy_Hall]

Let me guess, when interesting traffic arrives at the Fortigate it is able to successfully start a new VPN tunnel and start passing traffic.  However when interesting traffic arrives at the Check Point, IKE negotiations fail in Phase 2 and the traffic cannot pass.  Fortigates are similar to Juniper/Sonicwall in that Phase 2 subnet/Proxy-ID proposals presented to it must match its configuration precisely, unlike Cisco and Check Point who will accept a subset of their subnet/Proxy-ID configuration in a Phase 2 proposal.  You must adjust the Check Point configuration to present the exact subnet/Proxy-IDs that the Fortigate wants in Phase 2.

Read scenario 1 of this SK: sk108600: VPN Site-to-Site with 3rd party

And this SK for the proper filename of user*def file to edit: sk98239: Location of 'user.def' files on Security Management Server

You pretty much are stuck going down this road with Fortigate/Juniper/Sonicwall and to some degree Palo Alto interoperable VPNs.

Also as noted earlier make sure the Phase 1 and Phase 2 lifetimes match exactly, as Delete SA processing upon tunnel expiration does not always work correctly in an interoperable scenario and can cause tunnel hangs.

[Maarten_Sjouw]

Please check with the Fortigate people if they have set the rekey based on Kbytes. If they do they need to disable that, Check Point does not support this.

[Maarten_Sjouw]

When the Other party has set the rekey on KBytes, this exactly the behavior you would see. They Reset the tunnel when they recieved/sent the number they set and then drop the tunnel from their end, you do not notice this as they expect you to do the same.

[Jesus_Cano]

rekey is 28800 secons. (not KB).

Fortinet side has enabled el Autokey keep alive, we will monitor how it works now

[Jesus_Cano]

Issue is still happening, when not traffic is in the tunnel goes down. And we need to renegotiate in order to up again. Why is this happening, how can we know the reason?

[Timothy_Hall]

As a last resort, try checking the boxes keep_IKE_SAs and ike_send_initial_contact on the Global Properties...Advanced...Configure...VPN Advanced Properties...VPN IKE Properties screen and reinstall policy to the gateway.  Note that these are global settings (not per VPN Community) and may impact the operation of other unrelated VPN tunnels.

[Oskar_Svedman]

I had a similar issue between R80.10 and SMB 730 gateways before. (Used Dynamic IP of the remote SMB gateways)
Needed to force a reset of the tunnel before it went back.

I got a hotfix from CheckPoint that solved my problem.