PIX: IPSec Phase 1 Failure

[rsgamage1]

Hi,

I'm experiencing IKE phase 1 failures when the tunnel initialization is attempted from the remote site. The local peer has PIX 7.0(4) whereas remote peer has a Checkpoint FW.

IKE Phase 1 parameters are as follows;

Authentication Mode: Preshare Key

Authentication Algorithm: MD5/HMAC-128

Encryption: 3DES-168

Diffie-Hellman Group: Group 2

Lifetime Measure: Time

Time Lifetime (seconds): 86400

PFS: OFF

If the tunnel is initiated by the remote peer(181.168.1.49)..tunnel initialization fails.

--------

Jun 12 14:34:49 192.168.1.1 Jun 12 2008 14:34:49 pix : %PIX-5-713092: Group = 181.168.1.49, IP = 181.168.1.49, Failure during phase 1 rekeying attempt due to collision

Jun 12 14:34:49 192.168.1.1 Jun 12 2008 14:34:49 pix : %PIX-7-715065: Group = 181.168.1.49, IP = 181.168.1.49, IKE MM Responder FSM error history (struct &0x744f668) <state>, <event>: MM_DONE, EV_ERROR-->MM_SND_MSG6_H, EV_SND_MSG_OK-->MM_SND_MSG6_H, EV_SND_MSG-->MM_SND_MSG6, EV_SND_MSG-->MM_BLD_MSG6, EV_ENCRYPT_OK-->MM_BLD_MSG6, NullEvent-->MM_BLD_MSG6, EV_ENCRYPT_MSG-->MM_BLD_MSG6, EV_CHK_PROPOSAL

---------

If the tunnel is initiated by the local peer it completes Phase 1 however the rekey timer is set to 64800 seconds !!

---------

Jun 12 19:51:59 192.168.1.1 Jun 12 2008 19:51:59 pix : %PIX-3-713119: Group = 181.168.1.49, IP = 181.168.1.49, PHASE 1 COMPLETED

Jun 12 19:51:59 192.168.1.1 Jun 12 2008 19:51:59 pix : %PIX-7-713906: Group = 181.168.1.49, IP = 181.168.1.49, Starting phase 1 rekey timer: 64800000 (ms)

----------

Explanation for %PIX-5-713092 and %PIX-7-715065 messages say that this can be software related. All the excerpts of logs are related to the local device(PIX).

1) What is your experience and opinion about this incident.

2) Why does the tunnel reinitializes in every 64800 seconds and NOT 86400 seconds?

3) A similar error "Failure during phase 1 rekeying attempt due to collision" on VPN concentrator corresponds to mismatched rekey-timers.

Ref:http://www.cisco.com/warp/public/471/vpn3k-conn.html

Could this also be of a similar nature ?

4) Could anything interesting be grasped from %PIX-7-715065 log ?

Thanks in advance for your attention.

[ranilgamage]

It is interesting to see the way things are interpreted by different people with different kind of experiences. It is indeed important to get things clarified and I consider this to be the best way.

I thank you for your thoughts/ideas/experiences shared already.

Michael's argument can not be fully nullified because as he has pointed out this of course may be device dependent.

Could anyone share his/her experiences with regard to my original post please?

Interestingly for %PIX-5-713092, Cisco Syslog guide says it is related to an "Internal software error".

Ref:

http://www.cisco.com/en/US/docs/security/asa/asa70/system/message/logmsgs.html#wp1286192

However, so far this was observed with this particular VPN only; There are multiple VPNs terminated at the local peer.

Has anyone come across a similar issue before?

[cisco24x7]

I've setup a couple of hundred VPN tunnels between Checkpoint

and Cisco. I am not an expert in this area but enough but

enough to be dangerous:

1- what is the checkpoint version on the other side?

NG with AI, NGx R60/61/62 or R65? can you provide the

"fw ver" output?

2- Is this Secureplatform or Nokia? "uname -a" can help

3- Is this VPN setup in traditional or simplified mode? You

should be using Simplified because you have better control

of phase I and II timeout settings

Each vendors has different intepretation of IPSec. For the

most parts, you should be setting the phase I and II timeout

EXACTLY on both sides. Just because Cisco sends a smaller

phase I timeout to Checkpoint does not mean that CP will

accept it even though the whole thing will work but it will

break sometime later and produce unpredictable results

[rsgamage1]

I can only answer to Q1.1 for the moment.

It is NGx R61.

[cisco24x7]

Ask the Checkpoint firewall admin to do this:

1- log onto the firewall,

2- run "vpn debug trunc",

3- run "vpn debug ikeoff",

4- run "vpn debug ikeon",

Now initiate your vpn. He then can collect

the debug in the ike.elg file. That file

can be viewed with IKEView.exe and can point

out to you exactly where things go wrong

[rsgamage1]

Thanks for the troubleshooting snip. Will try to get this done by the remote party.

Would you rule out what PIX Syslog says (internal software error)?

I would prefer to check this out locally to make sure that everything is fine at my end.

[Farrukh Haroon]

Michael what you define is a pretty well known thing for VPNs (I'm not sure if its an IETF thing tough), it is even mentioned in the ASA configuration guide:

http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/ike.html#wp1042213

"A match exists when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer policy specifies a lifetime less than or equal to the lifetime in the policy the initiator sent. If the lifetimes are not identical, the security appliance uses the shorter lifetime. If no acceptable match exists, ISAKMP refuses negotiation and the SA is not established."

Regards

Farrukh

[michael.leblanc]

Farrukh:

Thank you.

That confirms that a "match" in ISAKMP policy is dependent on the the initiator having an ISAKMP lifetime equal to or greater than the responder ... on that particular platform.

Would you estimate that this behavior would be dependent on the responder also being an ASA, given that the other participants are reporting different results with a non-ASA peer?

[Farrukh Haroon]

Yes Michael, the success of the VPN would be largely dependent on the other peer's implementation. If both sides are the ASA, then I think one will observe a behavior consistent to the one described in the official documents.

But surprisingly Saadat Malik (the book mentioned on this thread) says the reverse is true, "(the initiator) must have an IKE SA timeout that is equal to or less than the responder that it is setup up to accept"

I wonder which one is correct...

Regards

Farrukh

[Farrukh Haroon]

It seems to be an implementation dependent thing, as per the RFC:

http://rfc.net/rfc2407.html

4.5.4 Lifetime Notification

When an initiator offers an SA lifetime greater than what the

responder desires based on their local policy, the responder has

three choices: 1) fail the negotiation entirely; 2) complete the

negotiation but use a shorter lifetime than what was offered; 3)

complete the negotiation and send an advisory notification to the

initiator indicating the responder's true lifetime. The choice of

what the responder actually does is implementation specific and/or

based on local policy.

To ensure interoperability in the latter case, the IPSEC DOI requires

the following only when the responder wishes to notify the initiator:

if the initiator offers an SA lifetime longer than the responder is

willing to accept, the responder SHOULD include an ISAKMP

Notification Payload in the exchange that includes the responder's

IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the

RESPONDER-LIFETIME Notification Message type which MUST be used for

this purpose.

Regards

Farrukh

[rsgamage1]

My original post with regard to VPN connections between Checkpoint and PIX devices:

When Checkpoint (Initiator) has a "lower" lifetime value than that of the PIX(Responder), would the "PIX" device(Responder) accept it?

If YES, then Phase 1 failure has nothing to do with this lifetime mismatch.

Then it could be related to some (unclear)reason, like a PIX internal software error (as the SYSLOG code indicates).

Anyone with a similar experience please?

Many thanks for all your thoughts,etc.

[nomair_83]

I dont think so.

[ranilgamage]

Interesting observation: PIX seems to take 75% of the configured rekey timer.

86400 X 75% = 64800

Apparently, this rekey-timer of 64800 has nothing to do with the Phase 1 lifetime of Checkpoint Responder. (It's P1 lifetime is 28800)

[rsgamage1]

Farrukh,

Thanks for the DOI related information.

What would be the behavior, when multiple VPNs are to be established with the SAME encryption, hash, authentication, DH parameter values but with DIFFERENT Phase 1 lifetimes ?

If the Responder checks only for the first 4 parameters, then would having several phase 1 policies differentiated only by the lifetime work ?

For e.g.

policy 1

encr 3des

hash md5

authentication pre-share

group 2

lifetime 3600

crypto isakmp policy 2

encr 3des

hash md5

authentication pre-share

group 2

lifetime 28800

Can one match these policies exactly with two different VPN peers having corresponding lifetimes?

What are the conditions?

[Farrukh Haroon]

Yes two policies can theoretically be matched, but since the responder compares the initiators proposals payload one by one (with all of its configured policies) as soon as it matches any one it stops the matching process and displays 'atts are acceptable' (if debug is on), so the second one never gets matched.

That is why its a best practice to keep your 'most secure' policy (stronger encr. less lifetime etc.) at the top.

Michael thanks for testing it out. Seems to be a pretty vaguely documented thing to me, perhaps the best way is to test it out.

Regards

Farrukh

[michael.leblanc]

Farrukh:

Figure 13-14 in Saadat Malik's book (Network Security Principles and Practices) also shows initiation with a higher ISAKMP lifetime resulting in multiple decrementing offers before the responder was willing to return an "atts are acceptable" response.

When I tried this with an IOS platform, I did not observe this behavior in the ISAKMP debug on the responder.

It seems that knowing your specific platform is pretty important.

Thanks for digging up the RFC content. That supplemental info is much appreciated.