Using either net-misc/vpnc-0.5.3 (stable) or net-misc/vpnc-0.5.3_p449-r1 (testing) the VPN tunnel hangs after a certain time, in my case 1 hour. Debugging output shows that a 3600 s (=1h) session lifetime is negiotiated, after which rekeying is done. This rekeying fails, causing the tunnel to stop working. I tested a pair of patches on found on the vpnc-devel mailing list, that solved my issue: http://www.gossamer-threads.com/lists/vpnc/devel/3442 A lot of other people reported success with these pataches on Fedora too: https://bugs.launchpad.net/fedora/+source/vpnc/+bug/479632 I created an -r2 ebuild that simply applies the two patches, I maybe be useful to others to get it into portage. Reproducible: Always
Created attachment 258505 [details] vpnc-0.5.3_p449-r2.ebuild
Created attachment 258506 [details, diff] check-deleted-spi.diff
Created attachment 258508 [details, diff] reuse-socket.diff
Today there was one more patch fixing dropped connection committed by upstream to svn, please provide us with p451 revision while keeping these two patches in addition. as they fix a different issue. Author: Joerg Mayer Date: Fri Dec 31 03:07:00 2010 New Revision: 451 Log: Mihai Maties <mihai@xxxx.org> The Dead Peer Detection mechanism implemented in vpnc has a small issue. A lot of people are complaining about connections being dropped with the following error message logged: "connection terminated by dead peer detection" This is caused by vpnc sending incorrect sequence numbers to the VPN concentrator. The sequence numbers should be sent in big-endian byte order, however they are sent in little-endian byte-order (on some architectures). The initial SeqNo sent by vpnc is randomly chosen and it is subsequently incremented. However when the least significant byte rolls over (from vpnc's point of view) the other end notices that the current SeqNo is less than the previous SeqNo. This is an error message from a Cisco ASA showing the problem: Dec 20 02:48:26 10.233.170.24 %ASA-6-713124: Group = somegroup, Username = user.name, IP = 2.2.1.1, Received DPD sequence number 0x952942 in R_U_THERE, Next expected sequence number should be greater than 0xff942942 vpnc SeqNo real SeqNo ---------- ----------- 42 29 94 fd fd 94 29 42 42 29 94 fe fe 94 29 42 42 29 94 ff ff 94 29 42 42 29 95 00 00 95 29 42 <--- real SeqNo is less than previous one Depending on the initial [random] sequence number, the bug will terminate the connection on the first DPD sent or it could survive 255 DPDs (in the most favourable case). [TODO: A clean version of this fix would be to convert the values to host endianess on packet read and converting them to network order on packet send.] Modified: trunk/vpnc.c Modified: trunk/vpnc.c ============================================================================== --- trunk/vpnc.c (original) +++ trunk/vpnc.c Fri Dec 31 03:07:00 2010 @@ -760,7 +760,9 @@ */ s->ike.dpd_attempts = 6; s->ike.dpd_sent = time(NULL); + s->ike.dpd_seqno = ntohl(s->ike.dpd_seqno); ++s->ike.dpd_seqno; + s->ike.dpd_seqno = htonl(s->ike.dpd_seqno); send_dpd(s, 0, s->ike.dpd_seqno); } else { /* Our last dpd request has not yet been acked. If it's been @@ -1531,6 +1533,7 @@ if (s->ike.dpd_idle != 0) { gcry_create_nonce(&s->ike.dpd_seqno, sizeof(s->ike.dpd_seqno)); s->ike.dpd_seqno &= 0x7FFFFFFF; + s->ike.dpd_seqno = htonl(s->ike.dpd_seqno); s->ike.dpd_seqno_ack = s->ike.dpd_seqno; s->ike.do_dpd = 1; DEBUG(2, printf("peer is DPD capable (RFC3706)\n"));
This has been incorporated into the latest snapshot vpnc-0.5.3_p451, although slightly modifed. Thank you for your input and sorry for the delay, but I do not use vpnc anymore which lifts the pressure on me. If you are interested in helping maintaining this software, please contact me.
