Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

VPN 3000 disconnects posts

I've noticed a number of posts in regard to random disconnects as well as times when one can make a connection, but not pass any data through the tunnel.. Well after months of work with the TAC we found this CSCdx03837. We are running 3.6.3 on the concentrator and 3.5.1c on the client. The release notes for 3.6.3 say nothing about CSCdx03837, but if you step back to the 3.5.4 release notes for the concentrator its there... Anyway, thought I might share this and hopefully resolve anyone having this same issue and not having their secret cisco bug identifier search ring on.

4 REPLIES
e.l
Community Member

Re: VPN 3000 disconnects posts

Thanks for sharing. So, does it mean that v3.6.3 still has this bug ?

Regards

Community Member

Re: VPN 3000 disconnects posts

The bug is cleared up in 3.6.3 of the client and concentrator. Just make sure both are at 3.6.3 and it shouldn't be a problem.

Community Member

Re: VPN 3000 disconnects posts

This Bug looks like it is in reference to a concentrator behind a PIX firewall. I am not behind a pix firewall and still see the same issues.

Community Member

Re: VPN 3000 disconnects posts

I believe the reference is to the client being behind a PIX not necessarily the concentrator.

Also, when I've run into these issues I try to use TCP over IPSec. If that’s a problem try using IPSec over UDP and if that still isn't working you can always try it without transparent tunneling.

On occasion I will see users who get dropped over a dialup connection as well. The dialup stays connected, but the tunnel drops. In those instances its usually been a problem with latency that clears up later on or the next day. You can mess with the peer timeout value within the dialer and/or the forcekeepalives=1 option within the .pcf file.

Also consider this:

When using the VPN Client behind an ESP-aware NAT/Firewall, the port on the NAT/Firewall device may be closed due to the VPN Client's keepalive implementation, called DPD (Dead Peer Detection). When a client is idle, it does not send a keepalive until it sends data and gets no response.

To allow the VPN Client to work through ESP-aware NAT/Firewalls, add the ForceKeepAlives parameter to the *.pcf (profile configuration file) for the affected connection profile. This parameter enables IKE and ESP keepalives for the connection at approximately 20 second intervals.

Use the following syntax when adding this parameter to the [Main] section of any *.pcf file:

ForceKeepAlives=1

For more information, see "Connection Profile Configuration Parameters" in the VPN Client Administrator Guide.

Hope this helps..

95
Views
0
Helpful
4
Replies
CreatePlease to create content