8.3(2) Phase 2 rekey problems, or is it just me?

Unanswered Question
Aug 9th, 2010

Anyone getting problems with the inner SA collapsing when it tries to rekey in the newest loads?

debug looks like this:

[IKEv1]: IP = XX.XX.XX.XX, Unable to kick off reykeying!

[IKEv1 DEBUG]: Group = DefaultRAGroup, Username = xxxxx, IP = XX.XX.XX.XX, Active unit starts Phase 2 rekey with remote peer XX.XX.XX.XX

[IKEv1 DEBUG]: Group = DefaultRAGroup, Username = xxxxx, IP = XX.XX.XX.XX, sending delete/delete with reason message

... more packet level messages...

[IKEv1 DEBUG]: Group = DefaultRAGroup, Username = xxxxx, IP = XX.XX.XX.XX, Active unit receives a centry expired event for remote peer XX.XX.XX.XX

This leads me to a few followup questions:

1) I've been working on the ACLs a bit.  Can anyone think of a way an ACL or filter might get in the way of a rekey when it doesn't stop an initial negotiation?  I can't.

2) As a temporary workaround we want to extend the rekey until we find a fix.  It takes the lower of the client or ASA's rekeying interval.

Anyone got a quick link to how to set this on Windows XP, Windows Vista, and OSX?  The Windows boxen seem to send 3600 here.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
b.julin Sun, 09/12/2010 - 09:40

I'm bumping this back up with some updates, in hopes that someone, somewhere is also still running 8.3(2) with IPSEC/L2TP and hasn't just retreated back into 8.2(x).

The symptom here would be WIndows native clients disconnecting 57:30 or so into the connection.

I've been in touch with the TAC on this issue and the answer from them is "works for me (TM)."   I'm continuing to work on that to try to find out what might be different between TAC's configs/environment and mine but so far no luck.

If anyone has this running and does NOT see this problem I would really appreciate a debug log captured from the ASA commandline.  Especially I'd need the exact amount of time elapsed between the "PHASE 2 COMPLETED" during the initial connection and the start of the rekeying event.

If you HAVE experienced this problem I'd apppreciate just knowing that I'm not entirely alone here.

Tech details if you have this problem -- there's a workaround but it's ugly.

Basically you need to configure things so that the client always rekeys first.  The ASA's internal rekeying timer stops at 95% of the negotiated lifetime (in 8.3, still have to downgrade to see if this is the same in 8.2).  Windows normally negotiates a lifetime of 3600 seconds.  Windows starts it's rekey 80 seconds or so before the SA expiry.  So At 3600s lifetime the ASA rekeys first.

If the connection negotiates a lifetime of 1200s, then Windows gets first crack at the rekeying.  However getting there is not that simple.  Windows XP will negotiate down just fine if the ASA is configured for 1200s ("crypto ipsec security-association lifetime seconds 1200" or in the crypto map.)  However Vista and WIndows 7 cannot connect when the ASA is configured this way -- they refuse to negotiate downwards.

If you create a manual "IP Security policy" and set the ProhibitIpSec registry entry (google it) then you can force Windows clients to ask for and accept a 1200s lifetime.  The ASA can be left with a lifetime of 3600s or greater so unaltered clients can still connect.  This is the ugly part.  It's hard to distribute that to users (not all Windows systems have what is needed to automate IP Security Policy imports when not attached to a domain)  and it will mess up any other VPN connections they might have defined to other sites.

Another (extremely sleazy) workaround is just to make sure the user always transfers 250M of data every hour.  Windows clients will rekey first when the kilobyte-based lifetime expires.

b.julin Wed, 09/22/2010 - 10:25



Step 1) Look for a crypto map and a dynamic crypto map that have the same name.

Step 2) Don't do that.


This Discussion