SSD Nodes Learn Hosting plans →
How to do am Matt ConnorBy Matt Connor · Updated 2026-10-28

WireGuard vs OpenVPN: Which One You Go Self-Host?

WireGuard dey win for speed, small config, and audit surface. But OpenVPN still make sense for TCP 443-only networks, MFA, named users, or Layer 2 bridging.

Di short answer

WireGuard vs OpenVPN, for one person wey dey run VPN server for im own VPS, no be close contest: choose WireGuard. E smaller, e dey run inside Linux kernel, e connects within fraction of one second, and working client config na about ten lines. OpenVPN still get four real jobs, and if none of dem concern you, you no need am.

Those four jobs na to comot from network wey dey allow only TCP port 443, connect to existing certificate authority, authenticate named users with password or second factor, and bridge for Layer 2. Everything below na evidence behind this recommendation, plus the exact point wey each exception start to apply to you.

Why WireGuard win for people wey dey self-host

The codebase small enough to read. The WireGuard project get protocol implementation wey be roughly 4,000 lines of code. OpenVPN dey reach six figures once you count the OpenSSL library wey e depend on for every cryptographic operation. Size matter because every line na attack surface, and you or your reviewer no go read 100,000 lines. You fit read 4,000.

E dey run for kernel. WireGuard don dey mainline Linux since 5.6, so Ubuntu 24.04 and Debian 13 ship am without anything to compile. Packets dey encrypted where dem already dey, for kernel space, without copying dem go userspace process and back. Check am before anything else:

sudo modprobe wireguard && echo ok

For KVM VPS, command go print ok. For container virtualisation wey share host kernel, like OpenVZ or LXC, e go fail with Operation not supported, because you no fit load module into kernel wey no be your own.

Nothing dey negotiate. WireGuard get one fixed cipher suite: ChaCha20-Poly1305 for data, with Curve25519 keys. No version dey to downgrade, and no option dey to configure wrongly. OpenVPN dey negotiate cipher and TLS (transport layer security) version with each client. This give flexibility, but na also where misconfiguration dey happen. Server wey still get data-ciphers AES-256-GCM:AES-128-CBC fit happily fall back to CBC cipher for client wey no offer anything better, and the log no go flag the weaker cipher as problem. Where data channel offload dey available, OpenVPN go print note say CBC entry don switch offload off. This warning na about speed, not security.

The port no dey answer. WireGuard packet wey fail message authentication check dey dropped without any reply, so nmap -sU -p 51820 no fit tell WireGuard server from port wey firewall silently dey drop: both go return open|filtered. Only unfiltered port wey nothing dey listen on go expose itself, because kernel go answer with ICMP port unreachable and nmap go report am as closed. OpenVPN server for TCP mode go complete TCP handshake before e decide say you no welcome. That one don already prove to scanner say something dey there. OpenVPN over UDP with tls-crypt nearly quiet reach so. So this point na argument against running OpenVPN on TCP, not against OpenVPN itself.

Roaming free. WireGuard peer dey identify with public key, not address. Your laptop fit move from home go mobile hotspot, send one handshake from the new address, and server go update the endpoint wey e dey reply to. Nothing reconnect because nothing ever connect. OpenVPN fit do something similar with float, but client normally dey tear down and rebuild full TLS session. Na why lid-open pause dey noticeable for OpenVPN but e no dey happen for WireGuard.

Speed for 2026: di gap go narrow only with kernel offload

For many years, the honest speed argument be say OpenVPN dey copy every packet go userspace, encrypt am there, then copy am come back, while WireGuard never comot from kernel. For stock Ubuntu 24.04 server, na still so, and WireGuard dey faster by wide margin. Wetin change for 2026 be say OpenVPN fit now move im data path enter kernel too, when both kernel and OpenVPN version support am, and comparison wey ignore this don old.

OpenVPN 2.7 release for February 2026 with support for the upstream ovpn kernel module, wey merge into Linux 6.16. This one na DCO (data channel offload): control channel remain for userspace, while bulk data path move enter kernel, roughly as WireGuard don always dey do. For kernel and OpenVPN wey new enough to use am, throughput dey the same class instead of being far apart. Check wetin you actually get:

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

As of October 2026, stock Ubuntu 24.04 LTS dey release OpenVPN 2.6, no be 2.7, and ovpn module need 2.7. For that release, you fit get offload only through the older openvpn-dco-dkms package, wey build out-of-tree module against the kernel wey dey run, so e go rebuild whenever kernel upgrade happen. Na moving part be that, and WireGuard no get am. Ubuntu 26.04 LTS release OpenVPN 2.7.0 and Linux 7.0 kernel, both new enough for ovpn, so for that release, na modinfo line above you suppose check.

Read the fine print for DCO before you count am as reason to remain. E support Layer 3 tunnels only, e accept AEAD ciphers only (authenticated encryption with associated data: AES-GCM or ChaCha20-Poly1305), e no support compression, and for server e work only with topology subnet. Every one of these restrictions remove part of the flexibility wey be OpenVPN argument from the beginning. Fast OpenVPN na OpenVPN wey configure to look like WireGuard.

No trust anybody throughput number wey dem publish, including this page. For VPS, CPU allowance or network allowance dey usually set the limit, no be protocol. Measure your own with iperf3 running across the tunnel, then run am again outside the tunnel, and compare both results.

OpenVPN still dey useful for where

You need to come out through TCP port 443. WireGuard na UDP only, and dem no dey plan to add TCP mode. Hotel network wey filters only by port number go usually allow OpenVPN wey you configure with proto tcp-server and port 443. No mistake am for disguise: OpenVPN over TCP dey use im own packet framing instead of normal TLS session. So corporate firewall or proxy wey dey inspect or terminate HTTPS fit still recognise am and block am. WireGuard need wrapper like wstunnel or udp2raw to cross the same network. That one mean say you get one more process to run and keep patched. Note the conflict: if web server already dey hold TCP 443 for that IP address, one of the two must move.

You already dey run certificate authority. OpenVPN dey authenticate with X.509 certificates, so e fit enter the PKI (public key infrastructure) wey you already dey operate. Certificates dey expire by themselves, and you revoke one by adding am to certificate revocation list wey server dey read through crl-verify. WireGuard get no certificates, no expiry, and no revocation list. To remove peer, you edit server config and reload am. For ten peers, that one no be problem. For four hundred peers, with audit requirement, certificate model dey do real work for you.

You need named users, no be keys alone. OpenVPN fit hand authentication over to external system with auth-user-pass-verify or plugin like openvpn-plugin-auth-pam.so. Na so people dey add LDAP or one-time-password second factor. WireGuard get no concept of user at all. Key either dey inside config or e no dey. If your requirement be say "Sara must enter code from her phone", WireGuard no fit express that by itself.

You need Layer 2, or client for something ancient. OpenVPN with dev tap dey bridge Ethernet frames. This one matter for broadcast protocols and old LAN games. WireGuard na Layer 3 only, and e go always remain so. OpenVPN still get clients for hardware and operating systems wey no go ever see WireGuard app. Both reasons dey reduce, and dev tap no compatible with DCO. So when you use the bridge, you go take the slower path.

Wetin the two setups really dey cost you

WireGuard identity na one command. The parentheses matter because dem set the file mode before the key dey exist:

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

The OpenVPN equivalent na certificate authority wey you go own for as long as the VPN dey exist:

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 unfair. The CA gives you expiry and revocation, but e costs you a private key wey you must protect for years, renewal wey you must remember, and rebuild if you lose am. If you no dey use wetin e gives you, you dey pay for nothing. The complete WireGuard procedure, including forwarding, NAT (network address translation) and handshake failures wey fit waste one afternoon, dey inside the guide for self-hosting a WireGuard VPN on your VPS.

Wetin each one dey ask from your firewall

WireGuard need exactly one inbound rule, for UDP on the port wey dey inside ListenPort:

sudo ufw allow 51820/udp
sudo ufw status verbose

OpenVPN need UDP 1194 by default, or TCP 443 if na dat path you choose. Both still need IP forwarding turned on and a source NAT rule, because Linux box dey drop packets wey no address am. Na this same part apply to both protocols, and na here most reports of "the tunnel connects but there is no internet" dey come from. If ufw new to you, start with the basics of the ufw firewall on a VPS, and remember say most providers dey run another network firewall for their control panel: rule wey you add for the server no go do anything if packet no ever reach the server. Understanding wetin port be and how Linux dey listen on one go make both checks faster.

How to choose, in one paragraph

Run WireGuard unless you fit sabi the specific thing wey e no fit do for you. If you need TCP 443 to escape a restrictive network, run OpenVPN there, and consider running both: dem use different ports and fit coexist for one server without conflict. If you need per-user accounts or a second factor, no dey force WireGuard to handle am. Put an identity layer above am instead. A self-hosted Headscale control server dey use WireGuard underneath and add the account model, key distribution and device approval wey plain WireGuard leave for you.

OpenVPN na WireGuard Migration without outage

No conversion dey happen. OpenVPN PKI no fit turn into WireGuard keys, because WireGuard no get certificates wey you fit convert. Every client go get fresh key pair, and you go generate am the same way you generate the server own.

Migrate dem in parallel instead of switching at once. WireGuard for UDP 51820 and OpenVPN for 1194 fit run for the same box at the same time. So bring up wg0, confirm am with sudo wg show by listing recent latest handshake, then move clients one after another. When OpenVPN peer list stop to change, stop the service with sudo systemctl disable --now openvpn-server@server. Keep the CA files until you sure say everything dey okay, because you no fit rebuild revoked client with CA wey you don delete.

One thing wey genuinely no dey carry across na your username and password accounts, plus the revocation trail wey follow dem. Decide where you go keep dem before you switch off the old server, no be after.

FAQ

WireGuard dey faster pass OpenVPN?

For normal Ubuntu 24.04 server, yes, and difference dey wide, because WireGuard dey encrypt for kernel, while OpenVPN 2.6 dey pass every packet through userspace process. With OpenVPN 2.7 and the ovpn kernel module from Linux 6.16, data path dey also run for kernel, so both dey for the same class. Measure your own performance with iperf3 across the tunnel instead make you trust number from blog, because for VPS, na usually your CPU or bandwidth allowance dey set the limit.

WireGuard fit run over TCP port 443?

No, not by itself. WireGuard na UDP-only by design, and nobody plan TCP mode. To pass through network wey allow only TCP 443, wrap am inside tunnel like wstunnel or udp2raw. This one add process wey you must run and patch for both ends. If na your normal work environment be this restriction, OpenVPN with proto tcp-server and port 443 na the simpler answer for network wey dey filter only by port. But proxy wey dey inspect HTTPS fit still detect am and block am.

OpenVPN don insecure now?

No. Current OpenVPN with AEAD cipher like AES-256-GCM and tls-crypt enabled na solid VPN. The reason to choose WireGuard dey elsewhere: OpenVPN carry much more code and many more options, so e give tired administrator plenty ways to configure am wrongly. Fewer choices mean fewer wrong configurations.

Which one I suppose choose for personal VPN on VPS?

WireGuard. One key pair for each device, one config file of about ten lines, one UDP port open, and handshake wey finish before you notice say e start. Choose OpenVPN only if you regularly connect from networks wey block UDP, or if you must fit into certificate authority or user directory wey already dey exist.

Dis article help you?