Why did OpenVPN stop connecting after an Ubuntu upgrade?

VPN profiles that survived last week break after an Ubuntu release upgrade, and the log rarely mentions the upgrade at all. What it does name is the layer that failed: the TLS handshake, the cipher negotiated for the data channel, the package that was installed, or the copy of OpenSSL the binary loads at startup. Each layer has its own error shape and its own repair, which makes classification the first job and editing the second. Treat the profile as innocent until the log names it.

Which layer failed: handshake, cipher, package, or library

Read the client log before touching the profile. The earliest error in the output is the one that identifies the layer; everything printed after it is usually fallout from that first failure. When the client never starts at all, the VPN log is the wrong file to open.

Certificate and signature complaints, or a message about key length, come from the control channel and the library policy that governs it. A warning that opens with DEPRECATED OPTION belongs to data-channel negotiation instead.

An Unrecognized option line is a third category: the new binary no longer accepts a directive the old one tolerated, so the profile needs rewriting rather than the library needs relaxing. Packaging failures look different again because they happen before any tunnel code runs. A missing binary, a plugin that will not load, or a repository pointing at the wrong codename all produce that shape. Four symptoms, four places to look, and almost no overlap between the repairs.

When the handshake fails, the TLS policy is rejecting the certificate

Ubuntu 22.04 moved the system to OpenSSL 3, and the default security level in that branch is stricter about certificate signatures and key sizes than 20.04 was. A CA certificate signed with an older digest, or a key below the current threshold, now fails during the handshake. Since nothing has authenticated yet, the error reads like a wrong password or a dead server.

The narrow repair attaches a cipher string to this connection alone. In the desktop editor, open the profile, switch to the advanced settings, and put DEFAULT:@SECLEVEL=0 in the TLS cipher field. The NetworkManager keyfile takes the same value under [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Restart NetworkManager and reconnect, because the daemon caches parsed profiles and will otherwise keep using the copy it already holds. Know what the line does before you keep it: that setting is a threshold across several certificate and key parameters rather than a cipher name, so lowering it widens what the single profile accepts. Note which server required it and drop the setting once the operator reissues current material. Changing /etc/ssl/openssl.cnf reaches the same threshold for every program that reads that file, which is far beyond the VPN.

OpenVPN 2.6 needs the cipher listed for negotiation

Ubuntu 22.10 shipped OpenVPN 2.6, and in that release --cipher stops choosing the data channel by itself. The cipher must also be present in the negotiated data-ciphers list, or the client prints a deprecation warning and then fails to bring the tunnel up.

The NetworkManager plugin from the same period still wrote only the old directive. That detail splits the diagnosis, because a profile corrected by hand can connect from a shell and still fail from the desktop applet. Add the list to the connection file under [vpn]:

data-ciphers=AES-256-CBC

Use the value the server advertises rather than the one you remember; a server pushing AES-256-GCM will not negotiate with a client list naming only CBC. Restart the manager and reconnect, then repeat the attempt from a shell with the cipher passed explicitly for both negotiation and fallback:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

If that command brings the tunnel up, the server, the certificates and the credentials are all sound, and the manager's stored option is the only fault left. A warning about a keysize directive belongs to the same cleanup: comment it out and keep the original file beside the profile.

Package and plugin faults look like VPN faults

Not every post-upgrade failure is cryptographic. An OpenVPN repository added under a codename the release does not use produces a package that never installs, so compare what lsb_release -a reports against the list file you added. A missing universe component or security pocket produces a package that cannot be found at all. Both cases leave the profile untouched and the tunnel impossible.

Read the package manager's error before the VPN log. If the client was never installed, no amount of profile editing will produce a handshake.

Two-factor profiles that stop prompting are the plugin version of the same story. The challenge comes from an authentication plugin, and an upgrade that dropped or replaced it leaves the profile intact while the prompt disappears. Reinstall the supported plugin instead of deleting the second factor to make the connection work.

A vendor library can hide behind a policy error

One pattern deserves recognition because it defeats every policy fix. A hardware vendor configuration tool can install its own OpenSSL libraries and place them ahead of the system copies in the loader search path. The client then starts against a library nobody upgraded, and the startup failure looks exactly like a rejected certificate.

Reinstalling the VPN package does not change which library is found first, and lowering the TLS level cannot reach a library that never came from the system. Ask the loader which crypto objects the binary actually resolves:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Remove or repoint the vendor copy, then run the same check again. The expected version has to be the one in use before you return to the profile.

Pinning an older client buys time, not a fix

Holding the previous client version restores the tunnel for as long as the hold lasts. It also freezes security updates for that package and schedules the same breakage for the next upgrade, so treat it as a dated workaround rather than a resolution.

If you do pin it, hold the package explicitly so an unattended upgrade cannot undo the pin, write down the reason and the date to revisit it, and set a reminder for the provider's next profile release. The condition worth watching is a server profile that negotiates a current cipher; once that exists, the pin has no justification left. An unrecorded pin, by contrast, becomes an outage nobody can explain six months later, because the person who applied it has moved on and the file records nothing.

Next time a VPN dies after a release upgrade, take five questions in sequence: which layer produced the first error, did the TLS policy reject the certificate, is the cipher negotiable in both directions, did the package and its plugin actually install, and which library does the process load. Only after all five come back clean does a downgrade make sense.