VPN PHASE 1 rekeying problem with ASA-CHECKPOINT

[radoslaw.soltys]

Hi,

We have issue with VPN l2l dropping after PHASE 1 rekeying process.

VPN is establishing without any problems with initialization traffic from both local sites.

But when it comes to rekeying Phase 1(ASA is the initiator of rekeying process) then:

1.New PHASE 1 rekey process is established properly.

2.ASA sends message to CHECKPOINT to delete old Phase 1 SAs

3.Checkpoint answers to ASA to also delete old Phase 2 SAs and here is the problem.

4.ASA receives this message ald deletes old Phase 2 SAs

5.PHASE 2 is created from the begining, but current tcp connections between local sites are dropped

Phase 1 , and Phase 2 idle timers were setted to the same values at both ends.

Currently we use 14400s for Phase 1 and 1800s for Phase2 and this issue appears every 3 hours(75% of max idle time)

Pings are running from ASA's local subnet host to Checkpint's local subnet host every 60 seconds to keep connection running.

I have found strange thing:

Sometimes first Phase1 rekey process is working(without loosing old Phase2 SAs and the only difference in whole rekey process is in flags in logs:

good - 13:37:24 %ASA-7-713906: Group = B.B.B.B, IP = B.B.B.B, IKE SA MM:6cf559de terminating: flags 0x01000006, refcnt 0, tuncnt 0

bad - 16:37:23 %ASA-7-713906: Group = B.B.B.B, IP = B.B.B.B, IKE SA MM:3b57d414 terminating: flags 0x01000026, refcnt 0, tuncnt 0

We use:

ASA 5520 with failover active/standby, soft 7.08

Checkpoint NGX R65 HFA50 (latest R65 version)

But this problem appeared also with ASA 7.07,newest ASA 8, and some older checkpoint software

ASA sample log included in attachements:

It looks like it was some software bug, but I need expoert opinion about that?

Maybe someone have had similar problem ?

[Alexandro Carrasquedo]

does checkpoint support keepalives?

On your logs i see the following:

Keep-alives configured on but peer does not support keep-alives

Please disable keepalives on the ASA and test.

http://tools.cisco.com/Support/CLILookup/cltSearchAction.do?AT=gD&BM=t&CN=%22isakmp%20keepalive%22&IndexOptionId=8.0&IndexId=PIX/ASA

Alex.

[radoslaw.soltys]

Thx for suggestion, but it didnt helped.

[Alexandro Carrasquedo]

what logs do you have now? can you enable debug cry isa 200 & debug cry ips 200 and post the logs 5 minutes before & after the rekeying process? what do the logs on the checkpoint say? what if you remove the rekey on the checkpoint ... by rfc, the lowest rekey time will be the one that will take precedence, so in this case, ASA will force rekey despite the fact that checkpoint does not have any value in it.

[cisco24x7]

Please do the following on the Checkpoint firewall, if you want to be technically correct with Checkpoint terminology, Checkpoint Enforcement Modules:

vpn debug ikeoff

vpn debug trunc

vpn debug ikeon

Let it run for a while. After that, download the $FWDIR/log/ike.elg file to your desktop and open it with IKEView.exe program. It will tell you EXACTLY what wrong with the VPN tunnel.

I find this extremely useful.

Good luck!!!

[slicerpro]

Was this ever resolved?

[radoslaw.soltys]

Hi,

Nothing has changed after turning off keepalives except that there is no line

%ASA-3-713122: IP = B.B.B.B, Keep-alives configured on but peer does not support keep-alives (type = None)

[auraza]

Please capture the debugs from the ASA surrounding the problem, and post them here:

debug cry isa 200

debug cry ips 200

[radoslaw.soltys]

Hi,

I attached the logs.

Problem appears with subnet C.C.C.128 at 11:11:14 after rekeying phase 1.

Please see the ip legend from the logs:

-A.A.A.A is our ASA device for geteway and local subnet

-B.B.B.B is Checkpoint device

-C.C.C.128 is Checkpoint first local subnet which is destroyed after rekeying phase 1 process

-D.D.D.64 is Checkpint second local subnet which is working fine after rekeying Phase 1 process.

Earlier, I forgot to mention that second subnet D.D.D.64 is working fine but only because we dont initialize for rekeing. Only checkpint local site sends pings from this subnet and we are only answering for them.

[rschotola]

Hi,

I have exactly the same problem with ASA 55xx / Checkpoint site-to-site tunnels. We updated in between to the latest ASA 8.x firmware. The behavior is exactly the same as with all other revisions. It is unclear why the TCP sessions are dropped during rekey? Any update on this topic from you guys?

[masterloo]

To make a long story I've tried to determine a solution or workaround since July 2007 and recently had luck ;) This is an interoperability bug that Checkpoint and Cisco need to work out.

From what I've seen and tested this is a problem that's existed for many years, and only affects Checkpoint running on Nokia IPSO. (tested SecurePlatform R62 and R65)

Individual I was working with had observed the same symptoms present with:

Pix: 6.3, 7.0, and 7.1 to NG-AI R55 and NGX R65

I tested:

SecurePlatform (Splat) R65 w/ ClusterXL HA --- Cisco ASA 5505 7.2 = no problems

Nokia IP390 IPSO 4.2 b78 R65 --- Cisco ASA 5505 7.2 = issue reproduced

Nokia IP390 IPS0 4.2 b78 R65 --- Juniper/NetScreen NS25 5.4r9 = would lose a packet, but not established sessions

Nokia IP390 IPS0 4.2 b78 R65 --- Cisco 2600 router IOS 12.3 = would lose a packets, but not sessions

Nokia IP390 IPSO 4.2 b96 R65 HFA40 --- Cisco ASA 5505 7.2 == issue reproduced

recent tests:

Nokia Ip710 IPSO 4.2 b105 R65 HFA50 to ASA 5505 7.2 = issue reproduced (not as frequent for some reason)

Sequence of events observed when a phase 1 rekey occurs:

1) Phase 1 initiated by Cisco

2) 3 Delete requests

a. Delete request from Cisco about the old IKE SA (before the current).

b. Delete sent by Checkpoint FW about the last P2 from the old IKE SA.

c. Delete request from Cisco about the CURRENT P1 just negotiated in step 1. (this looks like the problem, something unique about what CP sends to cause Cisco to do this)

3) One of the sides initiates phase 1 which succeeds, then Phase2 is negotiated fine and the tunnel is back up and traffic flows

The recent tests on IP710 with IPSO 4.2 build 107 and R65 HFA50 I'm seeing a greatly reduced frequency of the failures (though when firing up transfers, scp or cifs, i see failure rate jump way up while having 50+Mb going through).

Solution:

I ended up trying the following because it had helped a similar issue (ISA fw to Splat phase2 rekey would lose est. session)

Add value:

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

Check that value was added:

ckp_regedit -p SOFTWARE/CheckPoint/VPN1

To remove value:

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

This change should keep the previous SPI active on MM rekey.

cheers,

Ryan

[CSCO12120576]

Hi all,

I know that it is quite old topic here.. but I have exactly the same issue on my ASA 5520

ASA Version 9.1 (6)

However a remote VPN peer is Microsoft Internet Security and Acceleration Server 2006

The issue with VPN l2l dropping after PHASE 1 rekeying process.
- In logs I see that ASA is starting Rekeying Phase 1 process
- after that there is a log message PHASE 1 COMPLETED
- then ASA see Duplicate Phase 1 packets
- ASA torn down these packets... and closing sessions with comment: Reason: User Requested
- after that new Phase 1 is established, and all Phase 2 tunnels also...
- The same thing as in above description: everything is happening after 3 hours.. Currently we use 14400s for Phase 1 and 1800s for Phase2 and this issue appears every 3 hours(75% of max idle time)

I am adding logs here..

M.M.M.M - is my ASA, local peer

R.R.R.R - is remote peer

Please help...