Checkpoint R65 and Cisco ASA IPSec VPN Drop

I ran into this issue where the Checkpoint R65 IPSec tunnel kept on dropping with Cisco ASA. I actually had faced an issue in the past like this and I thought it will be a good idea to document the solution.

I had tough time digging up the solution which I used some time back. Fortunately I had a badly written OneNote document which came to my rescue.

To troubleshoot the issue and to make sure you need the below solution here is what you need to do.

• Kernel Debug
• IKE Debug

Both the above need to be done on the Checkpoint end (Honestly, debugging Cisco will give no results.

Kernel Debug

The Kernel debug is simple to execute. Make sure you execute this when the tunnel is down. Log into the enforcement module (The security gateway) and execute the below command

fw ctl zdebug

You may also choose to use other commands like

fw ctl debug –buf 12288

Once you execute, it will start spitting out errors like

vpn_ipsec_decrypt Reason: decryption failure: Could not get SAs from packet

This will prove half the story that the issue is indeed what we think it is.

IKE Debug

The IKE Debug must be done in parallel and this might be a tough one to catch. In order to debug, you need to execute the command

vpn debug trunc

You may use “vpn debug ikeon” (Just for IKE debugging), this will store the debug logs in a location ($FWDIR/log/ike.elg) . Just read this file (You can use Checkpoint tools to do this) or read it plain and see if the ASA has sent a SPI delete Packet.

If both the debugs show “green” in our test, then as they say, If it looks like a apple, tastes like a apple, smells like an apple, then it should be an apple .

Why

So now we know that we have to apply the below mentioned fix. But before that, I will need to bore you with the reason of why this happens and blah blah blah … Read on …

The way the SPI negotiations work are different in checkpoint and other vendors … (I know, we don’t need to be told this ). In any event, we know that the IPSec tunnel has 2 phases. The Phase 1 normally secures the phase 2 negotiations and we also know that there are 2 different timers for them (Anyone who has ever configured IPsec with any vendor will have gone through this drill) so, where are we headed with this, you ask ?

Please remember one point, the Phase 2 timers are lesser than the Phase 1 timers (and also in multiple), like 8 hrs for Phase 2 and 24 hrs for Phase1. Did you notice that the phase 2 is actually a subset (3 times 8 is 24, meaning the third time, both phase 1 and phase 2 will renegotiate).

This was done for a reason, Normally when some firewall sends a “Delete the Phase1 SPI” packet, Checkpoint goes ahead and also deletes the Phase 2 which were made based on that particular Phase1 SPI, which is good in some ways, but Cisco on the other hand, treats both the SPI as different , so it deletes the SPI only after the timeout on that one expires. Get the picture yet ?

To explain the above solution, I have drawn a diagram , As you can see, after the phase 1 goes down, the Cisco end keeps the phase 2 (Green Box) but the Checkpoint has lost it. Since the Cisco has the phase 2, it will not try and re negotiate, but the Checkpoint will expect the cisco to renegotiate it.

Now, in a fraction of second, there is a rat race that begins and the firewalls try and re use SA’s and renegotiate and stuff, which brings down the tunnel for 10 – 15 mins

Fix

To fix this issue, we need to edit the registry. I would recommend you take full back up of every thing before you make the change.

The registry file is located in the checkpoint in the following location

“$CPDIR/registry/HKLM_registry.data”

To make the change

execute the following

ckp_regedit -a SOFTWARE/CheckPoint/VPN1 DontDelIpsecSPI_OnP1Del -n 1

cpstop

cpstart

As you can see the first line adds the registry entry that don’t delete the IPsec on P1 delete, then we need to execute the “cpstop” and “cpstart”

We should bed done at this point.

To verify, that the change is done properly, you can execute the following command

cat  $CPDIR/registry/HKLM_registry.data | grep DontDel

You will see an output and a line added in the registry which will confirm the change is done.

In the worst case, if you want to revert the change, please use the following

ckp_regedit -d SOFTWARE/CheckPoint/VPN1 DontDelIpsecSPI_OnP1Del -n 1

cpstop

cpstart

If you see the difference is “-a” has been replaced with “-d” (standing for add and delete respectively), once you have done this, you can again verify the line is gone by the above command

Hope you like this and this is helpful to you.  I am not very sure, but I think the same applies to R70 as well.