IPSec VPN Resets before Isakmp Lifetime Expires

[Chuan Liu]

Hi,

I have a IPSec tunnel between ASA5520 and 1841. The ISAKMP lifetime is set to the default 24 hours on both end. No volume limit is configured. But the tunnel resets itself 1.5 hours ahead every day. I need to keep the resetting at night so that my special application won't be broken during work hours.

I thougt the premature resetting was due to IOS version on the router. I upgraded to a new version but did not fix the problem.

Besides the resetting, everything else is working fine.

Any ideas are appreciated.

[#2]

You may try using the command "clear crypto isakmp sa". This command resets the ISAKMP SAs after failed attempts to negotiate a VPN tunnel. You may verify the configuration of IKE for Preshared Keys using this:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094761.shtml#diag

[Chuan Liu]

Hi,

My understanding is that the tunnel will be renegotiated when the ISAKMP lifetime expires. I set the lifetime to the default 24 hours. No volume limit is set. But 1.5 hours before the lifetime expires, the tunnel is broken and renegotiated. My appication is cut off for one minute. So this is not a smooth/graceful resetting. Are there any ways to do this?

Thanks.

[Thotsaphon Lueangwattanaphong]

Chuan,

I used to see this problem as well. Did you configure the same values on both sides? I mean, the same exact lifetime values of 2 phases have to be configured on both devices.

Toshi

[Chuan Liu]

Hi Toshi,

Yes, both sides do have the similar configuraitons.

Thanks.

Larry

[Daniela Herrera]

Do you have debug information at that time? Is there a specific error when the tunnel goes down or is it just the renegotiation?

The negotiation is supposed to start before the 24 hours, but even if it does, it should not bring the tunnel down. The purpose of the renegotiation is to keep the tunnel available.

I would suggest to retrieve the debugs at that time and see if the tunnel is actually going down and what is the error message.

If it's completely related to the negotiation, you should be able to modify the lifetime on both ends and see it fail at another specific time, that should help verify if that is the problem or if there's something else breaking the connection.

Regards,

[Chuan Liu]

Hi,

One on my logs in ASA is as follows. (IP address is modified.)

------------

Apr 16 2009 00:52:16: %ASA-4-113019: Group = ABC.ABC.177.202, Username = ABC.ABC.177.202, IP = NZ_Router, Session disconnected. Session Type: IPSecLAN2LAN, Duration: 22h:48m:33s, Bytes xmt: 983291523, Bytes rcv: 982279579, Reason: Idle Timeout

Apr 16 2009 23:40:50: %ASA-3-713902: Group = ABC.ABC.177.202, IP = ABC.ABC.177.202, Removing peer from peer table failed, no match!

Apr 16 2009 23:40:50: %ASA-3-713902: Group = ABC.ABC.177.202, IP = ABC.ABC.177.202, Removing peer from peer table failed, no match!

Apr 16 2009 23:40:50: %ASA-4-713903: Group = ABC.ABC.177.202, IP = ABC.ABC.177.202, Error: Unable to remove PeerTblEntry

Apr 16 2009 23:40:50: %ASA-4-113019: Group = ABC.ABC.177.202, Username = ABC.ABC.177.202, IP = NZ_Router, Session disconnected. Session Type: IPSecLAN2LAN, Duration: 22h:48m:32s, Bytes xmt: 751281811, Bytes rcv: 1447481492, Reason: User Requested

------------------

The disconnection reason can be either 'User Requested' or 'Idle Timeout'. When 'Idle Timeout', the application won't get dropped; when 'User Requested', the application gets dropped.

Thanks.