The Computer Oracle

vpnc - it keeps disconnecting after 24 minutes

--------------------------------------------------
Rise to the top 3% as a developer or hire one of them at Toptal: https://topt.al/25cXVn
--------------------------------------------------

Music by Eric Matyas
https://www.soundimage.org
Track title: Melt

--

Chapters
00:00 Vpnc - It Keeps Disconnecting After 24 Minutes
01:57 Accepted Answer Score 8
03:31 Answer 2 Score 4
03:49 Answer 3 Score 1
05:16 Answer 4 Score 1
05:43 Answer 5 Score 0
05:59 Thank you

--

Full question
https://superuser.com/questions/309723/v...

--

Content licensed under CC BY-SA
https://meta.stackexchange.com/help/lice...

--

Tags
#ubuntu #ciscovpnclient #vpnc

#avk47



ACCEPTED ANSWER

Score 8


There is a bug report that addresses this problem, dating from 2010-10-28, but unfortunately still unsolved. It seems like the disconnect time is somewhat individual, although the reported times are still longer than 24 minutes.

The article points to a fix described here, which requires the recompilation of vpnc.

If your problem is related to rekeying, then the article rekeying problem with 0.5.3 claims that the bug is new to version 0.5.3 and does not exist in 0.5.1.

[EDIT}

It seems like going back to 0.5.1 didn't work for you. It also seems as if vpnc disconnects are common to many Linux distributions.

I have found Fixing vpnc disconnect problem above version 0.5.x, which suggests that maybe one needs to go back even to 0.4.x. In any case, the article suggests a fix which probably does not relate to your case but you could try :

After all we have to turn off DPD at the client end as well (vpnc) what we can achieve 2 ways:

  • add "--dpd-idle 0" command line switch when invoking "vpnc"
  • better yet to add this line to the config file: "DPD idle timeout (our side) 0"

Further information: man vpnc

There is similar info coming from RedHat support : Bug 484114 - VPN disconnect every 5 mins.

You could try going to vpnc 0.4.x, but I am starting to wonder if the problem is on your side or with some setting of the vpn server : 24 minutes is too precise.




ANSWER 2

Score 4


Try changing the NAT traversal mode to cisco-udp, that solved it for me

NAT Traversal Mode cisco-udp

My Full config looks like this

IPSec gateway VPNHOSTIP
IPSec ID SAMPLESHAREDUSER
IPSec secret SAMPLESHAREDKEY
Xauth username SAMPLEUSER
Xauth password SAMPLEUSERPASS
IKE Authmode psk
#IKE DH Group dh2 # this is the default
DNSUpdate no
DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

My VPN conenction is still running after 20 hrs so far.




ANSWER 3

Score 1


Homepage of the VPNC project does not mention this to be a known problem, but I assume "phase2-rekeying" is still not that stable (based on reported bugs). Also note that

  • phase1-rekeying missing

Patched version of 0.5.3 (as the latest in SVN of the original project) release of VPNC at github includes:

I also would recommend a watch guard as an ultimate solution for reconnects https://github.com/dcantrell/vpncwatch/network if an automated mode is very much desired and remote side can still cause (software-unrelated) disconnects.

PS

Since VPNC is a reversed-engineered version of commercial implementation, disconnects with emerging version changes on the remote side can be expected to reappear until being found&fixed again.

Finally,there is an option of using native client (anyconnect) for linux. One of the disadvantages are that client side configuration abilities as DNS record update and no default route are hugely limited. Another, disconnects will still take place but on much rare occasions.




ANSWER 4

Score 1


I had the same problem, and none of the suggested solutions worked for me. In the end, I gave up on vpnc and tried the ShrewSoft vpn client. It's a bit of a hassle because you have to compile it yourself (and manually install any missing dependencies -- in my case, cmake, libedit2, flex, and bison). But it seems to work fine.

At the time of writing, you can download it from https://www.shrew.net/download/ike




ANSWER 5

Score 0


You might look at the --nat-keepalive option, perhaps try --nat-keepalive 1200

At one point this was a known bug, not sure if it ever got fixed.