APT hold or upgrade path: rolling back a VPN client

Client updates break tunnels, older versions keep working, and that leaves two obvious remedies. One holds the package where it is and waits for a fix; the other moves forward to a supported arrangement immediately. They are not equally safe, and neither is a maintenance strategy without an exit. Compare them on what they actually freeze before choosing.

Two remedies for one regression

Holding a package keeps the working version installed and stops APT from moving it. It buys time, keeps users connected, and leaves the underlying bug untouched. Moving forward means finding the supported release that fixes the regression, or changing the connection owner to something the distribution still maintains. It costs more work up front and removes the standing risk.

The choice depends on three facts you should have before deciding: which component regressed, whether a fixed release exists, and how long the temporary state can be tolerated.

Pin the failure before choosing either

A NetworkManager core update, a VPN plugin update and a resolver helper regression look identical from the user's seat and have different rollback candidates. Capture the exact packages, versions and the first new error.

apt-cache policy network-manager network-manager-openvpn
dpkg -l | grep -E 'network-manager|openvpn|wireguard'

Package metadata can be stale when the lists have not been refreshed, so read it as a hint and confirm against the version actually installed. Do not take a target version from a forum post; the same version string from another release can carry a different dependency set.

Compare what a hold covers

A hold prevents a package from being automatically installed, upgraded or removed. It does not freeze its dependencies, does not repair a connection, and does not make an old binary secure. That gap is the whole comparison. If the regression came from a library the client links against, holding the client changes nothing while the library keeps moving.

sudo apt-get -s install network-manager=1.42.4-1
apt-mark showhold

Simulate the downgrade first and read the proposed changes in full. A downgrade that removes a dependency the desktop needs is a different incident, and the simulation is the cheapest place to discover it. If a hold is genuinely the right temporary boundary, write it as a decision with an owner, a reason and a removal condition. An unowned hold becomes permanent infrastructure that nobody dares touch.

Compare the exit paths

The forward path is a distribution or vendor fix, applied after it is verified on an independent connection. That keeps the system inside its supported update stream and closes the exposure. The migration path replaces the client or the host with something the distribution still maintains. It is more work and often the only honest answer when the regressed component has no fixed release in that release branch.

sudo apt-mark unhold network-manager
sudo apt update
sudo apt full-upgrade

Whichever exit you choose, verify the exact profile, authentication path, routes, DNS behaviour and reconnect before declaring it done. A tunnel that comes up once is not the same as one that survives suspend, a network change and a reboot. Keep the failing evidence for the bug report: package versions, journal excerpts, the profile structure with secrets removed. Never attach private keys or credentials to make a report more complete.

What the record must contain

Write the decision down in four lines: what regressed, what was held or changed, who owns the temporary state, and what removes it. Add the verification you ran, because the next engineer will repeat it.

A hold with an exit date is a managed rollback boundary. A hold without one is an unexplained downgrade that has quietly become part of the infrastructure.