VPN connections are dropped on cable modem links

[pmarkov]

We're using Cisco VPN Clients 3.5.1(Rel) with VPN3000 Concentrator.

Some users sitting on cable modem links have their VPN connections dropped at least twice per day before any inactivity timeouts expire, often in the middle of active work.

The users see the following message:

"Your IPSec connection has been terminated"

We are using IPSec over UDP for NAT transparency.

The users run telnet applications and Outlook.

Any ideas will be greatly appreciated

Thank you

[edadios]

Are you doing all tunneling or split tunneling?

If it is all tunneling, some ISP has some sort of heartbeat (keepalive) type mechanism on their network that could cause the timing out.

[ddemers]

We've found that IPSec over TCP and a slightly lower MTU will solve this problem. Hope that helps.

[jwanker]

we are running ipsec over tcp. tried low mtu settings and forcing keepalives and we still have a number of cable and dsl users getting disconnected.

[alexm]

We are having the same problem with Cisco VPN Client 3.5.2 and VPN 3005 3.5.3, even over MTU 1500 fast ethernet connections with just a router between the client and the gateway. It has happened only once over a dialup connection, but happens regularly over home broadband and faster connections.

We've tried connections both with and without TCP port 10000 tunnelling, and with and without Force Keepalives in the .pcf file. The failure rate seems to increase if the Stateful Firewall Always On is enabled, but disabling it doesn't eliminate the problem.

From the packet dumps and client logs I have, it appears that the client built-in firewall passes port 500 (IKE) keepalives for a while, then blocks a single one. From that point onward, the client sends keepalives regularly, but they never leave the client machine. All other traffic (e.g. ICMP) continues unaffected. Since the client thinks it has sent keepalives, but receives no keepalive responses, it concludes after a while that the connection has timed out and it destroys the SA.

Sometimes the client can reconnect, but often it fails to start the negotiation and throws the "remote peer is no longer responding" error. Restarting the client network interface (or rebooting) seems to reset the client firewall, permitting new connections to be established.

Simultaneously, other clients are able to connect to the gateway with no problems.

I haven't seen anything else on the Cisco site regarding this. Does anyone else have any more info?