vpnc Weak-Cipher Error: Gateway Policy or Desktop Fix?

Two repairs look equally quick when a legacy vpnc connection refuses to come up: pass the old weak-cipher flag, or drop in a wrapper script that adds it for you. They are not equivalent, because one changes a single profile's policy and the other changes the behaviour of every program that calls that path. The first question is whether the gateway still offers a weak proposal at all, and the second is who is allowed to accept it. Everything else follows from those two answers.

Two Repairs With Very Different Blast Radius

A profile-level change touches one connection, one owner and one expiry date. Replacing the installed binary touches every frontend on the machine, including the desktop applet a colleague uses for a completely different gateway profile. The wrapper also hides the change from whoever debugs the host six months later.

Package verification is the first casualty: a file at /usr/sbin/vpnc that no longer matches its package turns a routine security update into an investigation. Upgrades then either overwrite the wrapper silently or refuse to apply, depending on how the package manager treats modified files. Neither outcome appears in the connection log, which is why the wrapper approach stays attractive right up to the first incident. A single line in a profile is far easier to find and to remove than a binary nobody remembers replacing.

What the Deprecated Switch Actually Does

The vpnc manual marks the single-DES option as deprecated in favour of a weak-encryption setting, and documents a separate option that permits no encryption for data traffic at all. Those are different concessions with different consequences. Neither of them makes a modern gateway negotiate something it no longer offers.

Read the failure stage before choosing a repair. A rejected proposal and a rejected password produce similar frontend messages but completely different evidence.

Where a Scoped Exception Belongs

If an organisation knowingly accepts a legacy peer for a limited period, the exception belongs in that peer's profile, with an owner, a review date and a migration path to a supported protocol. Keeping it out of the global path is the whole point of calling it scoped.

Have the gateway owner confirm which algorithms the peer still proposes and what replaces it. A client flag cannot repair a proposal the server no longer sends, and a server migration that nobody scheduled will outlive the workaround. Put the review date in the same ticket as the exception, so the concession expires instead of becoming permanent.

Check the Negotiation, Not Just the Green Icon

Collect evidence that identifies the stage rather than the mood of the dialog. The commands below are read-only, and the first two show which configuration and version are actually in play.

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

The third command reports files that no longer match the package, which is how a forgotten wrapper announces itself. The fourth shows the concessions the profile carries, so an exception cannot quietly spread to a second profile through a copied file. Run both before and after a change, and keep the output with the connection profile rather than in a chat window.

Keep debug output out of tickets until somebody has read it, because the manual warns that the highest debug level dumps authentication data including passwords. The acceptance criterion is an authorised, supported agreement between client and gateway, not a menu entry that finally turns green. If the peer only offers a broken algorithm, the honest outcome is an exception with an end date or a replacement protocol, and that decision belongs to whoever owns the gateway. Recording the decision is the difference between a managed exception and an accidental policy change.