Connection Times Out After 20 Min with "IPSec SA Idle Timeout"

[bmunroe]

One of our users who connects to the VPN3000 via a home broadband connection consistently gets dropped every 20 minutes (see log below). None of our other users have timeout or autodisconnect problems (some stay connected for days on end).

61673 12/10/2002 21:48:13.140 SEV=5 IKE/50 RPT=2642 66.218.226.189

Group [<mycompanygroup>] User [<user>]

Connection terminated for peer 5406 (IPSec SA Idle Timeout)

Remote Proxy 192.10.12.92, Local Proxy 206.19.244.201

What does "IPSec SA Idle Timeout" mean? The VPN3000 is not receiving replies/heartbeats from the client as it should, therefore ti times out?

Hypotheses regarding disconnect:

1. The user's ISP does not allow IPSec connections for extended periods of time. The ISP's router is killing the connections at set intervals.

2. The user's home switch/router (combo device) is faulty or generally not up to the challenge of maintaining an IPSec connection for extended periods of time.

3. ????

Any assistance would be greatly appreciated. Thanks in advance.

[charles.manley]

I have a similar issue with a number of users though connecting via a LAN. From the logging it looks like a IPSec SA timeout, but the session idle timeout is WAY before the SA timeout.

What we see is they stay connected, but don't pass any traffic thru the tunnel after 15-20 min. I can't even ping them from the concentrator even though they are still technically connected.

HELP!

[kdurrett]

I like you. Your like a dream cisco customer for TAC. Usually Cisco is the first to be blamed :>), whether its Cisco fault or not. How many users does this affect? Is it a isolated incident, any other users using the same isp or home devices that are having the same problem? The idle timeout means that no traffic is being sent across the tunnel so its dropped. The heartbeats are more like "AYT" (are you there) packets, that is just to make sure that the client is still there and the tunnel is active, it doesn't keep the tunnels up. What used to happen is that the client would loose connection and couldn't reestablish the connection until its previous connection timed out. What is your idle timeout set to on the 3000, default is 30 minutes. You can increase that time to like, ah I forget and I dont have access to a 3000 to check, but its really high so basically it will never timeout or just change it to zero which will give you the same affect.

ISP is only a concern if its AOL usually. You can eliminate your first conclusion by doing ipsec over udp or tcp since your connecting to a concentrator. That should remove the isp from the equation.

Your second could be a possibility, maybe its a nat/pat translation timeout. Do you know what type of device this is if any? Connect via dialup if possible, if you got the same problem, it eliminates the home users device, if you connected to a different isp it would also eliminate them.

Maybe its a issue with the software version you are running as well, you are running the latest client and 3000 code right?

Kurtis Durrett

[charles.manley]

Well in our case I haven't been able to narrow down a specific ISP with this issue. I support memebers connecting to various networks and not all of them have issues. The ones that do we can have two or three memebers there with the exact same issue. They connect, but either can't recieve any data or they connect and can transfer for about 15 min and then lose the connection. The tunnel ALWAYS stays active though.

Our SA timeout is set for 8 hours our session idle time or group timeout is 4 hours so the group should always timeout before the SA.

One specific case, a user is behind a PIX firewall with UDP ports 500 and 10000 open to him both ways. He connects, but can't transfer any encrypted data. It either discards them or bypasses them. There are no other devices in his way.

We are running 3.6.3 code on the concentrators and 3.5.1c on the client though we have upgraded this one individual to 3.6.3 client as well and it does the same thing.

[bmunroe]

“How many users does this affect?”

Currently just one, but I’d like to get to the bottom of it so I can be prepared the next time it happens.

“Is it a isolated incident, any other users using the same isp or home devices that are having the same problem?”

It appears to be an isolated incident. So far this is the only user I know who goes through this particular ISP (CableAmerica). The others are using a COX or Sprint solution.

As far as the “Idle Timout”…

Get ready to see my ignorance. I could only find one place that allows me to set timeout parameters (see below). What is the link path to the setting you’re referring to? Also, as I mentioned in my original post, no one else gets dropped (timed out). Some users stay connected for days.

Administration | Access Rights | Access Settings

Session Idle Timeout (seconds) [ 600 ] Enter the administrative session idle timeout. Limit is 1800 seconds.

”Your second could be a possibility, maybe its a nat/pat translation timeout. Do you know what type of device this is if any?”

I don’t know what make/model the user’s device is. I’ll check it out.

”Maybe its a issue with the software version you are running as well, you are running the latest client and 3000 code right?”

The concentrator is running “Cisco Systems, Inc./VPN 3000 Concentrator Version 3.6.1”

The client is v3.52

I will investigate some ideas you proposed and then let you know what happens and/or ask for additional advice. Thanks for the speedy response!