IPSec between PIX and Checkpoint NG - SA Renew Problems

[dgaar]

Hi all,

i have here a IPSec VPN Connection between a Pix 515 OS 6.3(5) and a Checkpoint NG AI R55(HFA16) on Ipso 3.8(51)(HFA6). We did the configuration like the Cisco recommendation.

The Tunnel itself works fine (setup&traffic), the Problem is the SA Renew-Process: Every time when the Checkpoint initiate a SA Renew, they create a new IKE Session! Sometimes the Renew Process is OK, they using the new SA learned over the Session and the older IKE-Session get timed out, sometimes the PIX got confused over all the different IKE Sessions and the Tunnel stop working for a time ...

We tried many Settings (different DH-Groups, 3DES/AES Transform-Sets, with/without PFS and so on ...) - no results.

Did anybody got this behaviour too ?

[umedryk]

Please check the troubleshooting section in pix-checkpoint config at http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008009420f.shtml#tshoot

[chasm_Ger]

Hello dgaar,

we got this Problem too. We use the cisco 2811 12.3 T(6) Sec-K9. The peer uses the Checkpoint VPN-1 Firewall Version NG R55 with Application Intelligence

(R55) HFA_06 for IPSO 3.8, Hotfix 624 - Build 004.

The tunnel works fine for days and weeks, but then it fails and needs some minutes (2-6 min) while the Checkpoint sends renew requests and the cisco logs, that it receives the ike requests "with no sa" and after the expire timer gets out, it needs the "some" minutes while the checkpoint sends the requests on and on, the cisco ignores them and then (without an special reason) it accepts the ike packet and builds up the tunnel again.

We tried a troubleshoot, i have found. the cisco ios has an attack detection for to much ike requests. this isstandard activated with 3des and md5. We changed both, ike and ipsec, to aes and sha1. But the tunnel was broken down again with the same log messages.

Could you figure out a solution for this problem?

[dgaar]

Hi,

i´m sorry, we found no solution to fix this behaviour.

We increased the lifetime to 8h so the interruption occurs not so often ...

regards

Dietmar

[attrgautam]

Can you force isakmp keepalive and check ?

crypto isakmp keepalive 10

[chasm_Ger]

Hello,

currently we only have crypto isakmp nat keepalive 20 configured.

What is crypto isakmp keepalive 10 for?

thanks for your help

[chasm_Ger]

Hello,

it seems to fix the problem. Since i have configured the router with the keepalive, there was no break down of the tunnel any more.

I will post, if there will be a failure - like before the change - again.

Thanks for your help!

chasm_Ger

[chasm_Ger]

Hello Dietmar,

thats the next thing confusing me. In the log files, the tunnel is re-initiated in unregular time intervals (5minutes, 15 minutes and so on). I asked the admin of the peer for idle timer, but he said that nothing in that way is configured.

The isakmp lifetime and ipsec lifetime is 3600 seconds.

But the tunnel does not break in this intervals. It runs for days but then it breaks two times in 15 minutes for example.

Which lifetime did you increase?

regards

Matthias

[dgaar]

Hi Matthias,

we changed to 14400/28800 seconds.

We have the Problem exactly durig rekeying of IPsec-SAs.

But i will the try keepalive setting, i´m not shure how this will work with the Checkpoint.

regards,

Dietmar

[chasm_Ger]

I have configured the keepalive as well.

Now I'm waiting for the next possible failover...

[octavio.rocha]

Hi,

Did you find a solution for this problem? I am having the same issue.

thanks

[chasm_Ger]

Hi,

since i have done the solution by attrgautam, the tunnel does not fail any more.

I used the "crypto isakmp keepalive 10" in the config mode, and it works!

regards

chasm_Ger

[chasm_Ger]

Last week we got the same break down again. It looks this way:

the checkpoint peer sends ike messages - see this log entries:

May 26 2006 10:49:59.969: ISAKMP (0:0): received packet from 150.150.150.160 dport 500 sport 500 Global (N) NEW SA

May 26 2006 10:49:59.969: ISAKMP: Found a peer struct for 150.150.150.160, peer port 500

May 26 2006 10:49:59.969: ISAKMP: Locking peer struct 0x43A1941C, IKE refcount 2 for crypto_isakmp_process_block

May 26 2006 10:49:59.969: ISAKMP: local port 500, remote port 500

May 26 2006 10:49:59.973: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 43A1A960

May 26 2006 10:49:59.973: ISAKMP:(0:0:N/A:0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

May 26 2006 10:49:59.973: ISAKMP:(0:0:N/A:0):Old State = IKE_READY New State = IKE_R_MM1

May 26 2006 10:49:59.973: ISAKMP:(0:0:N/A:0): processing SA payload. message ID = 0

May 26 2006 10:49:59.973: ISAKMP:(0:0:N/A:0): processing vendor id payload

May 26 2006 10:49:59.973: ISAKMP:(0:0:N/A:0): vendor ID seems Unity/DPD but major 175 mismatch

May 26 2006 10:50:02.261: ISAKMP (0:268435514): received packet from 150.150.150.160 dport 500 sport 500 Global (R) MM_SA_SETUP

May 26 2006 10:50:02.265: ISAKMP:(0:58:HW:2):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

May 26 2006 10:50:02.265: ISAKMP:(0:58:HW:2):Old State = IKE_R_MM2 New State = IKE_R_MM3

May 26 2006 10:50:02.265: ISAKMP:(0:58:HW:2): processing KE payload. message ID = 0

May 26 2006 10:50:02.317: ISAKMP:(0:58:HW:2): processing NONCE payload. message ID = 0

May 26 2006 10:50:02.317: ISAKMP: Looking for a matching key for 150.150.150.160 in default : success

May 26 2006 10:50:02.317: ISAKMP:(0:58:HW:2):found peer pre-shared key matching 150.150.150.160

May 26 2006 10:50:02.317: ISAKMP:(0:58:HW:2):SKEYID state generated

May 26 2006 10:50:02.317: ISAKMP:(0:58:HW:2):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

May 26 2006 10:50:02.817: ISAKMP (0:268435514): received packet from 150.150.150.160 dport 500 sport 500 Global (R) QM_IDLE

May 26 2006 10:50:02.817: ISAKMP: set new node -1832376622 to QM_IDLE

May 26 2006 10:50:02.817: ISAKMP:(0:58:HW:2): processing HASH payload. message ID = -1832376622

May 26 2006 10:50:02.817: ISAKMP:(0:58:HW:2): processing DELETE payload. message ID = -1832376622

May 26 2006 10:50:02.817: ISAKMP:(0:58:HW:2):peer does not do paranoid keepalives.

May 26 2006 10:50:02.817: ISAKMP:(0:58:HW:2):deleting SA reason "No reason" state (R) QM_IDLE (peer 150.150.150.160)

May 26 2006 10:50:02.821: ISAKMP:(0:58:HW:2):deleting node -1832376622 error FALSE reason "Informational (in) state 1"

May 26 2006 10:50:02.821: ISAKMP:(0:58:HW:2):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

May 26 2006 10:50:02.821: ISAKMP:(0:58:HW:2):Old State = IKE_P1_COMPLETE New State = IKE_DEST_SA

May 26 2006 10:50:02.821: ISAKMP:(0:58:HW:2):deleting SA reason "No reason" state (R) QM_IDLE (peer 150.150.150.160)

May 26 2006 10:50:09.733: ISAKMP:(0:54:HW:2): retransmitting phase 2 QM_IDLE 1936832665 ...

May 26 2006 10:50:09.733: ISAKMP:(0:54:HW:2):incrementing error counter on sa: retransmit phase 2

May 26 2006 10:50:09.733: ISAKMP:(0:54:HW:2):incrementing error counter on sa: retransmit phase 2

May 26 2006 10:50:09.733: ISAKMP:(0:54:HW:2): retransmitting phase 2 1936832665 QM_IDLE

Our vpn endpoint ignores the requests from the other peer for key exchange and locks the peer struct.

After five minutes he unlocks it again (timeout????) and the tunnel could be established again.

Is it possible to minimize the timeout or this stupid behaviour?