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
Diffie-Hellman Group: Group 2
Lifetime Measure: Time
Time Lifetime (seconds): 86400
If the tunnel is initiated by the remote peer(188.8.131.52)..tunnel initialization fails.
Jun 12 14:34:49 192.168.1.1 Jun 12 2008 14:34:49 pix : %PIX-5-713092: Group = 184.108.40.206, IP = 220.127.116.11, 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 = 18.104.22.168, IP = 22.214.171.124, 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 = 126.96.36.199, IP = 188.8.131.52, PHASE 1 COMPLETED
Jun 12 19:51:59 192.168.1.1 Jun 12 2008 19:51:59 pix : %PIX-7-713906: Group = 184.108.40.206, IP = 220.127.116.11, 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.
One question out of the original context please.
Technically speaking, shouldn't it work for anything less than 84600 seconds at the remote end?
Remote site( < 86400) -- Local (= 86400)
tunnel initiated by Remote end should complete Phase 1 without any problem ?
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:)...
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?
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?
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)
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.