WireGuard vs OpenVPN: which to self-host

The short answer

WireGuard vs OpenVPN, for one person running a VPN server on their own VPS, is not a close contest: pick WireGuard. It is smaller, it runs inside the Linux kernel, it connects in a fraction of a second, and a working client config is about ten lines. OpenVPN keeps four real jobs, and if none of them is yours, you do not need it.

Those four jobs are getting out of a network that allows only TCP port 443, plugging into an existing certificate authority, authenticating named users with a password or a second factor, and bridging at Layer 2. Everything below is the evidence behind that recommendation, and the exact point where each exception starts to apply to you.

Why WireGuard won for self-hosters

The codebase is small enough to read. The WireGuard project puts its protocol implementation at roughly 4,000 lines of code. OpenVPN is in six figures once you count the OpenSSL library it leans on for every cryptographic operation. Size matters because every line is attack surface, and neither you nor your reviewer is going to read 100,000 lines. You could read 4,000.

It runs in the kernel. WireGuard has been in mainline Linux since 5.6, so Ubuntu 24.04 and Debian 13 ship it with nothing to compile. Packets are encrypted where they already are, in kernel space, with no copy out to a userspace process and back. Check it before anything else:

sudo modprobe wireguard && echo ok

On a KVM VPS that prints ok. On container virtualisation that shares the host kernel, such as OpenVZ or LXC, it fails with Operation not supported, because you cannot load a module into a kernel that is not yours.

There is nothing to negotiate. WireGuard has one fixed cipher suite: ChaCha20-Poly1305 for data, with Curve25519 keys. There is no version to downgrade and no option to get wrong. OpenVPN negotiates the cipher and the TLS (transport layer security) version with each client, which is flexibility, and which is also where misconfiguration lives. A server left with data-ciphers AES-256-GCM:AES-128-CBC will happily fall back to the CBC cipher for a client that offers nothing better, and nothing in the log calls that a problem.

The port does not answer. A WireGuard packet that fails its message authentication check is dropped with no reply at all, so nmap -sU -p 51820 returns open|filtered whether or not anything is listening. An OpenVPN server in TCP mode completes the TCP handshake before it decides you are not welcome, which is enough to prove to a scanner that something is there. OpenVPN over UDP with tls-crypt is nearly as quiet, so this is an argument against running OpenVPN on TCP rather than against OpenVPN itself.

Roaming is free. A WireGuard peer is identified by its public key, not by its address. Your laptop moves from home to a mobile hotspot, sends one handshake from the new address, and the server updates the endpoint it replies to. Nothing reconnects because nothing was ever connected. OpenVPN can do something similar with float, but the client normally tears down and rebuilds a full TLS session, which is why the lid-open pause is noticeable on OpenVPN and is not on WireGuard.

Speed in 2026: the gap has narrowed

For years the honest speed argument was that OpenVPN copied every packet into userspace, encrypted it there, and copied it back, while WireGuard never left the kernel. That is no longer the whole picture, and a comparison that ignores this is out of date.

OpenVPN 2.7 shipped in February 2026 with support for the upstream ovpn kernel module, which was merged into Linux 6.16. This is DCO (data channel offload): the control channel stays in userspace, and the bulk data path moves into the kernel, which is roughly what WireGuard has always done. On a kernel and an OpenVPN new enough to use it, throughput is in the same class rather than a different one. Check what you actually have:

uname -r
openvpn --version | head -n 1
modinfo ovpn 2>/dev/null | head -n 3

As of July 2026 a stock Ubuntu 24.04 LTS ships OpenVPN 2.6, not 2.7, and the ovpn module needs 2.7. On that release you get offload only through the older openvpn-dco-dkms package, which builds an out-of-tree module against your running kernel and therefore rebuilds on every kernel upgrade. That is a moving part WireGuard does not have.

Read the fine print on DCO before you count it as a reason to stay. It supports Layer 3 tunnels only, it accepts only AEAD ciphers (authenticated encryption with associated data: AES-GCM or ChaCha20-Poly1305), it does not support compression, and on a server it works only with topology subnet. Every one of those restrictions removes a piece of the flexibility that was OpenVPN's argument in the first place. Fast OpenVPN is OpenVPN configured to look like WireGuard.

Do not trust anybody's published throughput number, including this page. The ceiling on a VPS is usually the CPU allowance or the network allowance rather than the protocol. Measure your own with iperf3 running across the tunnel, then again outside it, and compare the two.

Where OpenVPN still earns its keep

You need to get out over TCP port 443. WireGuard is UDP only, deliberately, and there is no TCP mode coming. A hotel network or a corporate proxy that permits only TCP 443 will pass OpenVPN configured with proto tcp-server and port 443, because that traffic looks like an ordinary TLS session. WireGuard needs a wrapper such as wstunnel or udp2raw to cross the same network, which is one more process to run and to keep patched. Note the conflict: if a web server already holds TCP 443 on that IP address, one of the two has to move.

You already run a certificate authority. OpenVPN authenticates with X.509 certificates, so it drops into a PKI (public key infrastructure) you already operate. Certificates expire on their own, and you revoke one by adding it to a certificate revocation list that the server reads through crl-verify. WireGuard has no certificates, no expiry and no revocation list. Removing a peer means editing the server config and reloading it. At ten peers that is fine. At four hundred, with an audit requirement, the certificate model is doing real work for you.

You need named users, not only keys. OpenVPN can hand authentication to an external system with auth-user-pass-verify or a plugin such as openvpn-plugin-auth-pam.so, which is how people bolt on LDAP or a one-time-password second factor. WireGuard has no concept of a user at all. A key is either in the config or it is not. If your requirement is "Sara must enter a code from her phone", WireGuard cannot express that on its own.

You need Layer 2, or a client for something ancient. OpenVPN with dev tap bridges Ethernet frames, which matters for broadcast protocols and for old LAN games. WireGuard is Layer 3 only and always will be. OpenVPN also has clients on hardware and operating systems that will never see a WireGuard app. Both of these are shrinking reasons, and dev tap is incompatible with DCO, so you take the slow path when you take the bridge.

What the two setups actually cost you

A WireGuard identity is one command, and the parentheses matter because they set the file mode before the key exists:

(umask 077; wg genkey > private.key)
wg pubkey < private.key > public.key

The OpenVPN equivalent is a certificate authority you now own for as long as the VPN exists:

sudo apt install -y easy-rsa
make-cadir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca
./easyrsa gen-req server nopass
./easyrsa sign-req server server

Neither list is unfair. The CA buys you expiry and revocation, and it costs you a private key you must protect for years, a renewal you must remember, and a rebuild if you lose it. If you are not using what it buys, you are paying for nothing. The full WireGuard procedure, including forwarding, NAT (network address translation) and the handshake failures that waste an afternoon, is in the guide to self-hosting a WireGuard VPN on your VPS.

What each one asks of your firewall

WireGuard needs exactly one inbound rule, for UDP on the port in ListenPort:

sudo ufw allow 51820/udp
sudo ufw status verbose

OpenVPN needs UDP 1194 by default, or TCP 443 if you chose that path. Both then need IP forwarding turned on and a source NAT rule, because a Linux box drops packets that are not addressed to it. That part is identical for the two protocols, and it is where most "the tunnel connects but there is no internet" reports come from. If ufw is new to you, start with the basics of the ufw firewall on a VPS, and remember that most providers run a second network firewall in their control panel: a rule you added on the server does nothing if the packet never reaches the server. Understanding what a port is and how Linux listens on one makes both of those checks faster.

How to choose, in one paragraph

Run WireGuard unless you can name the specific thing it cannot do for you. If you need TCP 443 to escape a restrictive network, run OpenVPN there, and consider running both: they use different ports and coexist on one server without conflict. If you need per-user accounts or a second factor, do not fight WireGuard about it. Put an identity layer above it instead. A self-hosted Headscale control server speaks WireGuard underneath and adds the account model, key distribution and device approval that plain WireGuard leaves to you.

Migrating from OpenVPN without an outage

There is no conversion. OpenVPN's PKI does not become WireGuard keys, because WireGuard has no certificates to convert into. Every client gets a fresh key pair, generated the same way as the server's.

Migrate in parallel instead of switching. WireGuard on UDP 51820 and OpenVPN on 1194 run on the same box at the same time, so bring up wg0, confirm it with sudo wg show listing a recent latest handshake, then move clients one at a time. When the OpenVPN peer list stops moving, stop the service with sudo systemctl disable --now openvpn-server@server. Keep the CA files until you are sure, because rebuilding a revoked client on a CA you deleted is not possible.

One thing genuinely does not carry across: your username and password accounts, and the revocation trail that went with them. Decide where that lives before you turn the old server off, not after.

FAQ

Is WireGuard faster than OpenVPN?

On a stock Ubuntu 24.04 server, yes, and by a wide margin, because WireGuard encrypts in the kernel while OpenVPN 2.6 moves every packet through a userspace process. With OpenVPN 2.7 and the ovpn kernel module from Linux 6.16, the data path is also in the kernel and the two are in the same class. Measure your own with iperf3 across the tunnel rather than trusting a number from a blog, because on a VPS the limit is usually your CPU or bandwidth allowance.

Can WireGuard run over TCP port 443?

Not on its own. WireGuard is UDP only by design, and no TCP mode is planned. To cross a network that allows only TCP 443 you wrap it in a tunnel such as wstunnel or udp2raw, which adds a process to run and patch on both ends. If that restriction is your normal working environment, OpenVPN with proto tcp-server and port 443 is the simpler answer.

Is OpenVPN insecure now?

No. A current OpenVPN with an AEAD cipher such as AES-256-GCM and tls-crypt enabled is a sound VPN. The case for WireGuard rests on something else: OpenVPN carries far more code and far more options, so it offers a tired administrator many more ways to configure it badly. Fewer choices means fewer wrong ones.

Which should I pick for a personal VPN on a VPS?

WireGuard. One key pair per device, one config file of about ten lines, one UDP port open, and a handshake that finishes before you notice it started. Choose OpenVPN only if you regularly connect from networks that block UDP, or if you must fit into a certificate authority or a user directory that already exists.