cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4223
Views
34
Helpful
30
Replies

PIX: IPSec Phase 1 Failure

rsgamage1
Level 3
Level 3

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.

30 Replies 30

nomair_83
Level 3
Level 3

Plz make sure that the remote end's lifetime is same like yours..i.e default 86400.

Regards,

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.

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,

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?

michael.leblanc
Level 4
Level 4

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.

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?

I'm not sure I understand your latest response.

I was indicating that what you are experiencing - is "expected behavior".

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)

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.

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.

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.

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.

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: