06-17-2008 01:18 AM - edited 02-21-2020 03:46 PM
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.
06-18-2008 12:19 AM
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?
06-18-2008 03:14 AM
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
06-18-2008 03:25 AM
I can only answer to Q1.1 for the moment.
It is NGx R61.
06-18-2008 03:36 AM
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
06-18-2008 08:44 AM
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.
06-18-2008 12:15 PM
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
06-18-2008 12:43 PM
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?
06-18-2008 06:01 PM
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
06-18-2008 06:28 PM
It seems to be an implementation dependent thing, as per the RFC:
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
06-19-2008 01:16 AM
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.
06-19-2008 02:56 AM
I dont think so.
06-19-2008 03:27 AM
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)
06-19-2008 07:46 AM
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?
06-19-2008 08:32 AM
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
06-19-2008 07:43 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide