PIX: IPSec Phase 1 Failure

Unanswered Question
Jun 17th, 2008


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


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


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

Jun 12 14:34:49 Jun 12 2008 14:34:49 pix : %PIX-7-715065: Group =, IP =, 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 Jun 12 2008 19:51:59 pix : %PIX-3-713119: Group =, IP =, PHASE 1 COMPLETED

Jun 12 19:51:59 Jun 12 2008 19:51:59 pix : %PIX-7-713906: Group =, IP =, 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.


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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (8 ratings)
nomair_83 Tue, 06/17/2008 - 03:40

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


rsgamage1 Tue, 06/17/2008 - 03:49

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.

nomair_83 Tue, 06/17/2008 - 03:57

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:)...


rsgamage1 Tue, 06/17/2008 - 04:21

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 Tue, 06/17/2008 - 07:40

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.

rsgamage1 Tue, 06/17/2008 - 07:58

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?

michael.leblanc Tue, 06/17/2008 - 08:20

I'm not sure I understand your latest response.

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

rsgamage1 Tue, 06/17/2008 - 08:47

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)

michael.leblanc Tue, 06/17/2008 - 10:00


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.

ranilgamage Tue, 06/17/2008 - 14:17

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;)


Please refer to Figure 13-14. "IKE and IPsec Lifetime Negotiation"

Is this obsolete ?

If you have any thing published lately, please kindly share.

michael.leblanc Tue, 06/17/2008 - 15:44

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.

cisco24x7 Tue, 06/17/2008 - 17:27


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?


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.

michael.leblanc Tue, 06/17/2008 - 20:05

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.

michael.leblanc Tue, 06/17/2008 - 20:59

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.

ranilgamage Wed, 06/18/2008 - 00:19

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".



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 Wed, 06/18/2008 - 03:14

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

cisco24x7 Wed, 06/18/2008 - 03:36

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 Wed, 06/18/2008 - 08:44

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 Wed, 06/18/2008 - 12:15

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:


"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."



michael.leblanc Wed, 06/18/2008 - 12:43


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 Wed, 06/18/2008 - 18:01

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...



Farrukh Haroon Wed, 06/18/2008 - 18:28

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 defines the payload layout for the

RESPONDER-LIFETIME Notification Message type which MUST be used for

this purpose.



rsgamage1 Thu, 06/19/2008 - 01:16

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.

ranilgamage Thu, 06/19/2008 - 03:27

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 Thu, 06/19/2008 - 07:46


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 Thu, 06/19/2008 - 08:32

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.



michael.leblanc Thu, 06/19/2008 - 07:43


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.

cisco24x7 Thu, 06/19/2008 - 09:15

Keep in mind that the author works for Cisco

and that the book was written for cisco

products, I am guessing that is the case.

Not every vendors implement IPSec exactly the

same way. Checkpoint does thing a little bit

different than Cisco, and so does Juniper.


This Discussion