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-17-2008 03:40 AM
Plz make sure that the remote end's lifetime is same like yours..i.e default 86400.
Regards,
06-17-2008 03:49 AM
One question out of the original context please.
Technically speaking, shouldn't it work for anything less than 84600 seconds at the remote end?
i.e. if,
Remote site( < 86400) -- Local (= 86400)
tunnel initiated by Remote end should complete Phase 1 without any problem ?
Please clarify.
06-17-2008 03:57 AM
If u have cisco device at the remote end then u dont need to match the life time and it will select the lowest lifetime but with different vendor u must:)...
Regards,
06-17-2008 04:21 AM
Hi Nomair,
Thanks for response.
Coming back to the original question:
Taking your point into account, if lifetime mismatch is the cause, then how would you explain the successful completion of Phase 1 when initiated by PIX?
06-17-2008 07:40 AM
When the configured ISAKMP lifetimes are different, the "initiator's" lifetime MUST be the longer of the two for an ISAKMP SA to be successfully negotiated.
The shorter of the two lifetimes will be the lifetime negotiated as the endpoint with the shorter lifetime is not going to agree to a lifetime longer than its configured policy.
06-17-2008 07:58 AM
Exactly ! that's what I've pointed out in my second response. (anyway.. out of the context of my actual issue)
Could you explain the possible reasons for my original post?
06-17-2008 08:20 AM
I'm not sure I understand your latest response.
I was indicating that what you are experiencing - is "expected behavior".
06-17-2008 08:47 AM
OK, Michael, with that argument do you mean to say that rekey timer "64800" (NOT 84600) is what the remote peer is configured with ? (Q2 in my original post)
06-17-2008 10:00 AM
Yes.
Since the "remote peer" has an ISAKMP lifetime configured (64800 sec.) that is "less than" the lifetime (84600 sec.) configured on the "local peer", Phase 1 will fail when negotiation is "initiated" from the "remote peer".
When negotiation is "initiated" from the "local peer", Phase 1 will be successful because the initiator (local peer) is configured with the greater ISAKMP lifetime.
However, the shorter of the two lifetimes (64800 sec.) will be the lifetime negotiated as the endpoint with the shorter lifetime (remote peer) is not going to agree to a lifetime longer than its configured policy.
This is expected behavior.
06-17-2008 02:17 PM
What "Network Security Principles and Practices" By Saadat Malik says is something else !
Please refer to the url below.
ISBN: (ISBN-10: 1-58705-025-0; ISBN-13: 978-1-58705-025-1; Published: Nov 15, 2002;)
http://book.soundonair.ru/cisco/ch13lev1sec4.html
Please refer to Figure 13-14. "IKE and IPsec Lifetime Negotiation"
Is this obsolete ?
If you have any thing published lately, please kindly share.
06-17-2008 03:44 PM
Published, ... that's funny. :>)
No, I'm not published. If we relied on answers from those that were published, most of us would be waiting a long time for responses to our questions. Ultimately we have to choose who we wish to believe.
I agree that your reference is contrary to my statement. My belief is based on what I have read. However, I have scanned my most likely sources, and have not been able to recover the info.
If it turns out that I am incorrect, that will be fine with me, as I care more that my beliefs are in alignment with reality, than whether a posted statement is correct.
Perhaps the best approach would be for you to verify the ISAKMP policy on the Checkpoint FW, and determine whether it is configured for 64800 sec (the policy agreed too).
If it is, then evidence would be contrary to the published article (i.e.: the Checkpoint FW having the lower ISAKMP lifetime should have successfully "initiated" and negotiated an SA).
Also, your book reference suggests that if the Checkpoint FW "initiated" negotiation with a higher ISAKMP lifetime, this would have resulted in at least one offer of a lower proposal (following initial rejection).
Would it have offered a lifetime lower than that of the responder (local peer)? Possibly, but I wouldn't think so. I would expect the negotiated lifetime to be the lowest of the two configured lifetimes.
Perhaps we will find out.
Thank you for the link.
06-17-2008 05:27 PM
Micheael,
You stated that:
"When the configured ISAKMP lifetimes are different,
the "initiator's" lifetime MUST be the longer of the two for
an ISAKMP SA to be successfully negotiated.
The shorter of the two lifetimes will be the lifetime
negotiated as the endpoint with the shorter lifetime
is not going to agree to a lifetime longer than its
configured policy."
I would like to know if this is something you see in
real-life production scenario or is this just an edcuated
guess from you?
LAN_1---router---Internet---Checkpoint_NGx---LAN_2
I have router ISAKMP phase I set to 86400 secconds.
I have Checkpoint NGx R65 firewall Phase I set to
43200 seconds.
From a host behind LAN_2, I can telnet/ssh to a host
behind LAN_1. The host behind LAN_2 always
initiate the connections and I have tcpdump and the
ike.elg file to prove it.
The VPN is up and running just fine in AES-256/SHA
and DH group 5.
How do you explain that?
P.S the default setting for Checkpoint
setting is 86400 seconds for phase I and
3600 for phase II.
06-17-2008 08:05 PM
The statement was based on a "belief" that I have held since May 22, 2005 (the date I made a written note, based on information from a source that I can not identify). Regretfully the source was not included within the note, and was accepted as factual.
I have performed tests with IOS devices this evening, and have found that the results are NOT in alignment with my previously stated belief.
I did an ISAKMP debug on a responder, and observed that despite the initiator's configured ISAKMP lifetime being greater than the responder's, the ISAKMP transform offered was deemed to be "atts are acceptable", when compared to local policy.
The ISAKMP SA was successfully negotiated, with an ISAKMP lifetime equal to the lower value (responder's). There was nothing in the debug to suggest that the responder was at all concerned with the mis-match.
I don't know if the previously held belief is platform/implementation dependent. But, I will be retiring that belief until (if ever) I see it for myself.
Thank you for challenging the belief.
It would appear that the original poster's issue relates to a cause other than ISAKMP lifetime mis-match.
06-17-2008 08:59 PM
Missed a key paragraph when I pasted together my response above:
When the initiator's configured ISAKMP lifetime was less than the responder's, the ISAKMP transform offered was deemed to be "atts are acceptable", when compared to local policy. The ISAKMP SA was successfully negotiated, with nothing in the debug to suggest that the responder was at all concerned with the mis-match.
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