OpenVPN vs WireGuard: choosing a VPN protocol for each server

OpenVPN vs WireGuard used to be an easy call for a VPN operator: WireGuard ran in the kernel, OpenVPN pushed every packet through a single-threaded userspace process, and speed settled it. That gap has narrowed now that OpenVPN's data channel has an in-kernel driver of its own. The choice per node turns on other things: which networks your users connect from, what state the server keeps about them, and what your client apps already speak. Below is a point-by-point comparison and an iperf3 method for your own hardware.

OpenVPN vs WireGuard at a glance

Cryptography: one fixed suite against a negotiated one

WireGuard is deliberately opinionated. Its handshake is the Noise IK pattern with Curve25519, data is sealed with ChaCha20-Poly1305, and hashing uses BLAKE2s. Its white paper says it intentionally lacks cipher agility: if a primitive ever breaks, every endpoint has to update. In exchange there is nothing to misconfigure and no downgrade to attempt.

OpenVPN uses TLS for its control channel and negotiates the data cipher. --data-ciphers defaults to AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305, all AEAD ciphers. OpenVPN 2.7 also drops static-key mode by default, no longer compresses data before sending, and enforces AES-GCM usage limits with the same margin as TLS 1.3. Agility costs complexity, but a fleet can prefer AES-GCM where CPUs accelerate it and keep ChaCha20 for clients that lack those instructions.

Code size and where the packets are processed

WireGuard's Linux implementation is under 4,000 lines of code, excluding the cryptographic primitives, according to its white paper. OpenVPN carries a full TLS library and decades of options: far more code that could hold a bug.

For throughput, what matters is where the data channel runs. Classic OpenVPN reads each packet from a tun device into userspace, encrypts it and writes it back. OpenVPN's own wiki names the two costs: packets enter and leave the kernel twice, and all client traffic goes through one single-threaded process. On a server with dozens of cores, an OpenVPN instance without offload encrypts on one of them.

Data Channel Offload (DCO) removes both. OpenVPN 2.6 added it through an out-of-tree ovpn-dco module. The rewritten driver, ovpn, was merged into Linux 6.16, released on 27 July 2025, and handles both UDP and TCP sockets. OpenVPN 2.7.0 shipped on 11 February 2026 and speaks only the new module's interface. TLS and rekeying stay in userspace; encryption and forwarding move into the kernel and can use several cores.

DCO has rules: dev tun only, AEAD ciphers only, no compression, and topology subnet on servers. If a config breaks one, OpenVPN turns DCO off and logs disabling data channel offload, so check for that line on every node. Debian 13 ships a 6.12 kernel; there you build the module from the ovpn-backports project or run a newer kernel.

The often-quoted chart in the WireGuard white paper compared it with userspace OpenVPN using AES-256 and HMAC-SHA2-256. That test predates DCO and today's default ciphers, so do not size a fleet from it.

Restrictive networks: UDP only, or TCP on port 443

Here OpenVPN still earns its place. WireGuard runs over UDP only. Its documentation says it does not support tunnelling over TCP and does not aim to hide from deep packet inspection; that is left to separate tools such as udp2raw or udptunnel, which your clients then have to bundle.

OpenVPN can run over TCP. On a hotel, corporate or campus network that only lets web traffic out, a TCP tunnel on port 443 often connects where UDP fails. With --port-share, an OpenVPN TCP server hands any non-OpenVPN connection to a web server on the same port, and since 2.7 one server process can listen on UDP and TCP at once.

TCP is a fallback, not a default. TCP traffic inside a TCP tunnel stacks two retransmission systems, and on a lossy path both back off together and throughput collapses. Offer UDP first and drop to TCP 443 only when UDP fails.

Roaming and reconnects

A phone moving from Wi-Fi to mobile data changes its public address. WireGuard handles this without a reconnect: each side sends to the most recent address it received an authenticated packet from, and the session carries on.

OpenVPN does the same with --float, over UDP only, and 2.7 adds client floating to the DCO drivers. Over TCP, a new address means a new connection and a new TLS handshake.

Privacy: what the server remembers

For an operator with a no-logs promise, this matters more than speed. WireGuard keeps each peer's last endpoint, the public address and port it last sent from, in the interface's peer table. wg show prints it next to the latest handshake, and nothing in the protocol clears it while the peer stays configured. A commercial service can add a layer on top: short-lived keys or tunnel addresses, removal of idle peers, configuration kept in memory only.

OpenVPN also holds each connected client's real address, in its status output and usually in its log. The difference is lifetime: when a client disconnects, its session is torn down. Whichever you run, decide where logs go and how long they stay, and tell customers.

Measure per-core throughput yourself

Gbps figures depend on CPU, packet size, cipher and kernel, so the only OpenVPN vs WireGuard benchmark worth trusting is one on the hardware you will deploy. Use iperf3 3.16 or later, which runs each parallel stream on its own thread, and test through the tunnel from a separate client machine so the tool does not compete with the VPN for CPU:

iperf3 -s -B 10.8.0.1                        # node: listen on the tunnel address
iperf3 -c 10.8.0.1 -t 60 -P 4                # client: upload through the tunnel
iperf3 -c 10.8.0.1 -t 60 -P 4 -R             # client: download through the tunnel
iperf3 -c 10.8.0.1 -t 60 -u -b 0 -l 1200     # client: UDP, near-MTU packets
mpstat -P ALL 1                              # node, second shell, during each test

Run the same tests outside the tunnel first for a baseline. Then compare WireGuard, OpenVPN with DCO, and OpenVPN started with --disable-dco, each OpenVPN case with AES-256-GCM and with ChaCha20-Poly1305. If mpstat shows one core pinned at 100% while the rest idle, that core is your ceiling and more clients will not raise it.

Choosing per node

Most fleets settle OpenVPN vs WireGuard by running both. WireGuard is the default on every node: fewer moving parts, kernel speed on any current distribution, silent to scanners. OpenVPN runs beside it with DCO on UDP plus a TCP 443 listener for users whose networks block UDP.

Bandwidth decides the server more than the protocol does. A VPN node receives every byte it sends, so plan port capacity for peak use in both directions. On servers for VPN, a 2 Gbps dedicated server starts at €259 a month with 2× Xeon E5-2630v4; the single EPYC 9254, with newer cores, is €529 at 2 Gbps or €769 on 5 Gbps dedicated servers. Servers for a VPN provider covers fleet sizing, VPN exit node hosting covers address reputation and conntrack, and WireGuard on a VPS is the fifteen-minute personal setup.

Frequently asked questions

Is WireGuard faster than OpenVPN?

Against classic userspace OpenVPN, usually yes, because one OpenVPN process encrypts on a single core. With the in-kernel ovpn module from Linux 6.16 and OpenVPN 2.7, both data paths run in the kernel and can use several cores. Measure on your own CPU with iperf3 through each tunnel before deciding.

Can WireGuard run over TCP port 443?

Not by itself. WireGuard uses UDP only, and its authors state that TCP tunnelling and traffic obfuscation are out of scope. Tools such as udp2raw can wrap its packets in TCP, but every client must then run the same wrapper. OpenVPN supports TCP natively and can share port 443 with a web server.

Which Linux kernel has OpenVPN DCO built in?

The ovpn module was merged into Linux 6.16, released in July 2025. It requires OpenVPN 2.7 or later, and 2.7 no longer works with the older out-of-tree ovpn-dco module that 2.6 used. On older kernels, such as Debian 13's 6.12, build the module from the ovpn-backports project.

Does WireGuard log user IP addresses?

It writes no logs, but it keeps each peer's last public address and port in memory, visible in wg show, for as long as the peer is configured. A VPN service that promises no logs has to deal with that itself, for example by removing idle peers, rotating keys or tunnel addresses, and never writing that state to disk.