Re: 8.3(2) Phase 2 rekey problems, or is it just me?
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.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...