Many small businesses run an OpenVPN server that someone set up years ago and nobody has touched since. It keeps working until the server's operating system is upgraded or a new laptop arrives with the latest client, and suddenly some or all users cannot connect. Debian 12 and 13 and Ubuntu 24.04 all ship the OpenVPN 2.6 series, built against OpenSSL 3, and together they drop several old defaults. This guide explains what typically breaks in an OpenVPN 2.6 upgrade, how to fix it properly instead of switching old settings back on, and what else to check while the configuration is open.
Ciphers: from cipher to OpenVPN data-ciphers
Older configurations often contain a line such as cipher BF-CBC or cipher AES-256-CBC, or say nothing at all and rely on the old Blowfish default. Since version 2.5, OpenVPN negotiates the data channel cipher from a list set with the OpenVPN data-ciphers option, and by default accepts AES-256-GCM and AES-128-GCM, plus CHACHA20-POLY1305 in 2.6 where the crypto library supports it. The cipher option is no longer added to that list automatically. Very old clients that cannot negotiate, or servers still configured only for Blowfish, fail to connect.
OpenSSL 3 adds a second barrier: it no longer offers Blowfish and other legacy algorithms unless its legacy provider is loaded explicitly. That option exists as a temporary bridge, not a destination. The lasting fix is to update the clients and let both sides negotiate AES-GCM or ChaCha20.
Compression is off by default
Configurations from the 2.3 and 2.4 era frequently include comp-lzo or a compress line. Compression combined with encryption can leak information about the traffic, known as the VORACLE attack, so OpenVPN compression has been discouraged for years. In 2.6, allow-compression defaults to no unless the configuration explicitly mentions compression. Mismatched settings between server and client show up as tunnels that connect and then pass no traffic. The clean fix is to remove compression from the server and from every client profile. If some clients cannot be updated right away, keep an explicit, asymmetric setting for a short transition only.
Certificates, keys and "CRL has expired"
Three certificate problems tend to surface during an upgrade:
- Weak old keys and signatures. OpenSSL 3, as configured on Debian and Ubuntu, rejects RSA keys shorter than 2048 bits and certificates signed with outdated hashes. A certificate authority created a decade ago with small keys has to be replaced, and every user needs a new profile.
- Expiring certificates. Current easy-rsa releases issue server and client certificates with a limited lifetime. Find the expiry dates now, not on the morning they lapse.
- An expired revocation list. If the server uses crl-verify, the certificate revocation list has its own expiry, 180 days by default in easy-rsa. When it passes, every client fails with "CRL has expired", even though nothing else changed. Regenerate it with easyrsa gen-crl, copy it to where the server reads it, and schedule the renewal so it cannot happen again.
OpenVPN server hardening while you are in there
An upgrade is a good moment to add the settings that old configurations lack:
- tls-crypt, or tls-crypt-v2 with a separate key for each client, encrypts and authenticates the control channel, so the server does not respond to anyone without the key. It hides the server from scans and blunts denial-of-service attempts.
- A minimum TLS version of 1.2 for the control channel.
- Per-user certificates plus a second factor, so a copied profile alone cannot connect.
- Firewall rules per group, so a contractor's profile reaches one application and not the whole office network.
- Data channel offload on Linux, new in 2.6, which moves packet encryption into the kernel for better throughput on busy servers.
Every option and its current default is listed in the OpenVPN 2.6 reference manual, which is worth keeping open during the work.
An OpenVPN 2.6 upgrade path without a Monday-morning outage
- Copy the current server configuration, keys and client profiles somewhere safe.
- List every client in use: operating system, client version and who it belongs to.
- Build the new configuration on a test instance or a second port, and connect one updated client of each type.
- Issue new profiles where certificates or ciphers change, and send users short instructions for the OpenVPN client setup on their devices.
- Switch over at a quiet time, and keep the old server ready to roll back until everyone has connected.
For a Linux VPN install built from scratch, the same checklist becomes the design: modern ciphers, no compression, tls-crypt and certificates with a revocation list that renews itself. If you would rather hand the work over, our OpenVPN setup service covers the certificate authority, firewall rules and client profiles.
Frequently asked questions: openvpn 2.6 upgrade
Do users need new profiles after the upgrade?
Only if something they hold changes: a new certificate authority, new certificates, a tls-crypt key or different cipher settings. Removing compression usually means editing the profile too, which is why many upgrades end with fresh profiles for everyone.
How do we keep the CRL from expiring again?
Schedule easyrsa gen-crl well inside the CRL lifetime, copy the new file to the path named in crl-verify, and alert when its next-update date gets close. Current versions reread the file when it changes, so no restart is needed, but it must stay readable by the user the OpenVPN server runs as.
Can old clients keep working during the transition?
For a short time, yes, by allowing their ciphers or compression explicitly on the server. Treat that as a deadline, not a permanent setting.
Clients failing after an upgrade, or an OpenVPN server nobody has looked at in years? Our OpenVPN installation and configuration service covers server hardening, certificates and per-user profiles for Windows, macOS, Linux and mobile, and as a VPN configuration service it fits into wider network and VPN security work for offices in Long Beach and Los Angeles. Contact us with the server's operating system version and the client versions your team uses.
