Your tunnel dies at a repeatable interval, which is a timer reporting itself rather than a bad cable. Twenty-four minutes is 1440 seconds, the kind of round value a profile or a head-end policy carries. The same configuration then fails against the same concentrator every time while every other network works, and no amount of link testing changes it.

Three conditions decide which timer is yours: whether the client gives up on an idle session, whether the rekey exchange is refused, and whether a translating gateway rewrote the encapsulation.

Which Timer Owns the Drop

Measure the interval across at least three reconnects before touching a setting. A spread of seconds points at link loss or a wireless roam; a value that lands within a few seconds of the same mark every time points at a policy value. Session length also tells you who ended it, because a client-side timeout and a server-side delete leave different final lines in the debug output. Three reconnects also reveal whether the interval drifts at all, which a single measurement cannot show.

Write the number down next to the head-end you were talking to. Once the interval is stable, the remaining work is choosing between three causes, and one changed setting per reconnect is what keeps them distinguishable.

Case One: the Client Abandons an Idle Session

vpnc runs its own dead-peer check, and that check can kill a session the concentrator still believes is alive, especially when a translating gateway sits between the two. The client-side remedy in the documentation is to switch the timer off locally and let the head-end decide when a peer is gone. Both lines below belong in the vpnc profile or on the command line, and both are independent of the encryption settings.

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

Disabling client DPD removes a false positive and also removes your only local detection, so apply it on its own and watch whether the interval changes at all.

Case Two: the Rekey Is Refused

If the interval survives the DPD change, phase 1 rekeying becomes the candidate. Older vpnc builds handled rekeying less carefully than current ones, and the Diffie-Hellman group is the usual disagreement. Forcing a group the head-end already accepts costs one line and one reconnect, which makes it a cheap experiment rather than a policy change.

IKE DH Group dh5

Valid group names are dh1, dh2 and dh5. A group the concentrator rejects produces an immediate failure, which is still information: it tells you the head-end is picky and the original group was probably correct.

Case Three: Translation Rewrites the Encapsulation

Behind a translating gateway, Cisco's UDP encapsulation and the standards-based mode are not interchangeable. The wrong choice frequently produces a tunnel that establishes, passes traffic, and then times out under load, which reads like a bandwidth problem and is not one. Change only the mode, then reconnect and time the drop again. Try the other mode only after the first two cases are ruled out.

Front-ends add their own confusion here. NetworkManager will not offer a vpnc connection type until the plugin package is installed, and a missing plugin shows up as a greyed-out Add button rather than an error. KDE's front-end keeps the same values in a profile of its own, so confirm the daemon reads what you edited.

A profile that connects fine from the command line but not from the desktop is a front-end problem, not a timer problem.

Verify the Exchange That Fails Before the Third Change

Run the client with debug output and read the last exchange before the drop. A phase 1 delete immediately before the disconnect means the client rekeyed and was refused. A phase 2 delete at the same point means the tunnel was torn down from the other side, and your client settings are not the cause.

vpnc --debug 3 office

Also check for a second network daemon when the tunnel survives but traffic stops. Two managers writing the routing table produce the same symptom from the desktop and a completely different log.

פֿאַרבונדענע אַרטיקלען