WireGuard vs OpenVPN: measured, then compared

Kernel WireGuard beat userspace OpenVPN 2.6.14 in our run, with a median of 3367 against 1933 Mbit/s (see the run table). It was one virtual machine, one cipher each and a bridge that runs at memory speed, so read how it was made before quoting either number.

For the router side of the same question, see OpenWrt and WireGuard and the throughput-per-CPU-cycle measurements.

That is what a protocol comparison looks like once you print the settings. The top results we read repeat ratios without naming the host, version or cipher.

The project that wrote WireGuard says of its own benchmark table that it is "old, crusty, and not super well conducted". So we ran a fresh one, kept the raw files, and wrote down what it cannot tell you.

On the other axis people raise, WireGuard's site states its aim as very few lines of code and easy auditing, compared with OpenVPN/OpenSSL and IPsec. That is the project's stated aim, not something we measured.

Is WireGuard faster than OpenVPN?

In this run, yes: kernel WireGuard had a higher median single-stream throughput than userspace OpenVPN on the same host, and every WireGuard run was above every OpenVPN run.

Here are the five rounds, summarised.

WireGuard did not win the round-trip row on average. The ping average is slightly lower for OpenVPN, 0.526 ms against 0.554 ms, while OpenVPN's single worst ping was more than twice WireGuard's. Fifty pings on a bridge inside one machine won't settle latency anyway.

The baseline needs a caution too. A no-tunnel stream between two containers reached 103687 Mbit/s because the packets never leave the machine. Both tunnels sit far below it, which tells you that encryption and the extra copies cost real throughput on this hardware, not that either would reach those numbers on a link.

This comparison also mixes two things. Kernel WireGuard is a protocol and a kernel implementation; OpenVPN here is a protocol and a userspace one. The difference you see in the table is both at once.

Our older dated measurements are about a different question, our own tunnel core against the kernel module and two other userspace implementations, and they are in Throughput per CPU cycle on real routers.

Does OpenVPN DCO change the comparison?

Yes, because DCO moves OpenVPN's data channel out of userspace, so a userspace number does not describe OpenVPN with DCO. OpenVPN's community wiki calls the feature Data Channel Offload, also written OVPN-DCO.

In our run it was off. The OpenVPN build carried the DCO code, but the guest's Linux kernel had no ovpn module and no /dev/ovpn device existed. The log said ovpn-dco was missing and that OpenVPN was "disabling data channel offload".

So the OpenVPN row above is userspace OpenVPN, the configuration you get on a kernel without the module. We did not run the DCO arm in this run; the dedicated-server run in the last section did.

If you plan to run OpenVPN on a Linux server you control, check whether your kernel can load the module before you read any OpenVPN speed figure, ours included. The wiki defines DCO as moving "the processing of data packets from the OpenVPN userspace program to a separate entity", offloaded to the kernel.

How do WireGuard and OpenVPN set up a session?

WireGuard runs one fixed handshake between two static public keys; OpenVPN opens a TLS session and uses it to agree on keys for a separate data channel.

WireGuard's protocol page names the construction Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s and says it is based on the Noise_IK handshake. A handshake message carries the sender's encrypted static key and a timestamp. The page lists these properties:

• avoiding key-compromise impersonation
• avoiding replay
• perfect forward secrecy
• identity hiding

The handshake repeats every few minutes so session keys rotate. An optional pre-shared key is mixed in, and when it is not in use, an all-zero value is assumed.

OpenVPN's TLS mode, in the 2.6 manual, establishes a control channel and a data channel multiplexed over a single port. The control channel is a TLS session over a reliability layer; the manual says it provides certificate-based authentication and Diffie Hellman forward secrecy, and that it is used to exchange the keys that protect the data channel.

In our run the OpenVPN log shows the result: a TLS 1.3 control channel with TLS_AES_256_GCM_SHA384 and a P-256 certificate, then a data channel with AES-256-GCM.

The connect-time row is not a clean TLS measurement. The OpenVPN timing window also covers starting the daemon, loading the certificates and keys and bringing up the tun device. The run did not separate any of that from the TLS 1.3 handshake.

What you can fairly expect from the shape of the protocol is that a tunnel that does certificate checks has more to do than one that checks a key it already knows.

Which ciphers do WireGuard and OpenVPN use?

WireGuard has no cipher menu; OpenVPN negotiates one. The protocol page lists WireGuard's fixed primitives:

• ChaCha20 for symmetric encryption, authenticated with Poly1305
• Curve25519 for key agreement (ECDH)
• BLAKE2s for hashing

It cites RFC 7539 for the ChaCha20-Poly1305 construction; that RFC has since been replaced by RFC 8439.

The 2.6 manual says that in 2.6 and later the default --data-ciphers list is AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305 when ChaCha20-Poly1305 is available, and that from 2.5 on the server's list order decides which cipher is picked. It also warns that clients based on the OpenVPN 3.x library have no configurable cipher option, so a server must keep one of the ciphers they use in its list.

We pinned OpenVPN to AES-256-GCM alone, and WireGuard stayed on its own fixed cipher, so the two arms did not use the same cipher.

On hardware with AES instructions that could favour OpenVPN; on hardware without them it could favour WireGuard. We did not run a ChaCha20 arm for OpenVPN, so we cannot say which way it moved the result.

The practical point for anyone choosing: a fixed suite leaves nothing to misconfigure, and a negotiated suite lets old and new clients meet in the middle. Which one you want depends on whether you control every client that connects.

Is WireGuard more secure than OpenVPN?

Neither the WireGuard protocol page nor the OpenVPN 2.6 manual ranks them, and we will not either. What they do describe are mechanisms you can weigh against your own risk.

Any sentence that says "X is more secure" without naming a mechanism and a source is a claim nobody has shown you the evidence for.

The mechanisms differ in shape. WireGuard has one handshake, a short list of primitives and a mitigation for handshake floods. The protocol page describes a cookie reply the server may send when it is under load, so it does not spend CPU on a Diffie-Hellman computation for an unverified sender.

OpenVPN has certificate authentication, optional username and password through --auth-user-pass, and a choice of data ciphers, all documented in its manual.

More options give more room to fit an existing system and more room for a weak combination. Fewer options give less of both.

That is a trade, and the right side of it depends on who runs the other end. A single-owner tunnel between your own devices rarely needs certificate revocation lists; a company with hundreds of users usually does.

If a security review is the reason you are reading, do not decide from this article. Read both primary pages above, then the version you will actually deploy. Version matters: the OpenVPN 2.6 manual says the default data ciphers changed between 2.5 and 2.6.

Does WireGuard work over TCP?

No: WireGuard's protocol page says all packets are sent over UDP. OpenVPN's manual lists "TCP or UDP tunnel transport through proxies or NAT", and its example client config tries UDP first and then TCP on a second port.

That asymmetry is one reason people keep OpenVPN around. When the only path available to a machine is a TCP stream, a UDP-only tunnel has nothing to ride on, and OpenVPN has a transport for it.

What do WireGuard and OpenVPN need configured?

WireGuard needs a key pair per peer and a list of which addresses each peer may use; OpenVPN needs a certificate authority, a certificate and key per machine, or a password backend, plus a cipher and transport choice.

The WireGuard side of that table is short because the project chose to leave things out. How a client learns a peer's key, or how a company hands out and revokes many of them, is outside the protocol. You build that with scripts or a management layer, and that is where managed products live.

OpenVPN's side is longer because it ships the pieces: certificates, a plugin and script system for authentication, and options for the data channel. The cost is a longer config and more to keep current.

On WireGuard, the interface size is set by the MTU.

Should you run WireGuard or OpenVPN on a router?

Run the one your router software already ships and your other end already speaks; if both are available, WireGuard needs less on the router and OpenVPN needs more but covers more cases.

On OpenWrt, WireGuard is a kernel interface, so the work is the key, the peer, a firewall zone and a forwarding rule. Our guide OpenWrt WireGuard: three ways to run a VPN compares all three routes, including an OpenVPN tunnel, and gives the manual WireGuard steps.

For hardware and the two shapes our own client takes, read MikroTik vs OpenWrt as a VPN router, and the install pages for OpenWrt and MikroTik list what is published.

A router's CPU is the constraint here, and the run above was not on a router. We would not read those two throughput figures as what a small router would do.

We did take a router measurement, but of a different pair: our core against RouterOS's own kernel tunnel, in the same post.

One check after any router recipe: once you bring a tunnel up, your devices should show a working connection. If the tunnel says it is up and pages still do not load, VPN connected but no internet maps the app's messages to causes.

Should you self-host WireGuard or OpenVPN?

Self-host WireGuard when you control every device and want a short config; self-host OpenVPN when you need TCP, per-user certificates, or password login.

For a handful of your own devices, a WireGuard server set up with wireguard-tools is one interface, one key pair per device and a NAT rule on the server so traffic can leave. The lab server in this run was set up that way: one interface and one peer.

Self-hosted WireGuard vs a VPN service times the build and lists the upkeep. The cost shows up later, when a device is lost and you must remove its key by hand, or when a friend wants access and you must hand them a config file.

OpenVPN fits where an organisation already has a certificate authority or a directory, where users come and go, or where the path to the server only carries TCP. Its manual describes scaling to hundreds or thousands of users.

If you want neither the key handling nor the server, that is a different decision from the protocol choice.

What does ForestVPN use, and where did it lose?

The ForestVPN core, Quantum, is our own tunnel engine, as the WireGuard compare page describes, and it speaks WireGuard's unmodified Noise_IKpsk2 handshake, as the protocol page describes. It is not OpenVPN.

Our core was not part of the container run above, so that arm is missing rather than estimated. It was part of two later Linux runs. The newer one, on 2026-10-30, ran on x86_64 virtual machines in our lab: two VMs of 2 or 4 vCPUs on one host (AMD Ryzen 7 8845HS), Ubuntu 26.04.1, kernel 7.0, OpenVPN 2.7.0 over UDP with AES-256-GCM in userspace and with the kernel's own DCO driver, against ForestVPN's Linux daemon at as many threads as vCPUs, iperf3 3.20, one TCP stream for 15 s, median of 5 runs (OpenVPN run). OpenVPN moves one stream through one process or one kernel path, so it got no extra threads: this is each tunnel as it runs, not a matched-cores test.

ForestVPN's core carried 2.5 and 2.8 times what OpenVPN with DCO did, and 16 and 14 times userspace OpenVPN, at 12.7 and 14.2 CPU cycles per byte against DCO's 22.6 and 23.6 (whole host, both ends). It lost on latency: ping p99 under that load was 5.52 and 3.92 ms for our core against 1.43 and 1.85 for DCO and about 1.5 for userspace OpenVPN. Over a 2.5 Gbit/s link between two other hosts, every tunnel but userspace OpenVPN reached the link, and DCO used the least host CPU per gigabit of any, 0.48 CPU seconds against our 0.67 (whole host, no-tunnel baseline not subtracted). These are OpenVPN 2.7.0 figures; they say nothing about 2.6, and the kernel module carried less at 4 vCPUs than at 2 for reasons we have not found.

The older run, on 2026-10-16, measured the build before the 2026-10-30 changes on dedicated Linux servers, described on the compare page: two Scaleway instances of one type on a private network, Ubuntu 24.04.5, kernel 6.8.0-142, iperf3 3.16, one TCP stream for 20 s, median of 5 runs. ForestVPN's Linux daemon ran at its default single thread, with its optional extra key exchange off. OpenVPN 2.6.19 used AES-256-GCM and the WireGuard family ChaCha20-Poly1305, so the cipher differs.

On that earlier build, ForestVPN's core carried about 2.1 times what userspace OpenVPN did on x86 and 2.7 times on arm64. It lost to kernel WireGuard by about three times and to OpenVPN with DCO by about two times, at one thread. OpenVPN with DCO also used fewer CPU cycles per byte on arm64 (32.3 against 39.7) and tied on x86 (17.9 against 16.4, ranges overlap). A second run of the same earlier build on 2026-10-17 (thread sweep) gave our core more threads on the same two dedicated types, on a different pair of instances; there the kernel module and wireguard-go still carried about 1.9 to 2.4 times our best, and OpenVPN was not part of it. The compare page has that run and does not mix its figures with these.

Older dated figures from the throughput post are about other hardware: on two MikroTik routers on 2026-09-01, our core reached 122 Mbit/s against 66.8 Mbit/s for RouterOS's own kernel tunnel, and lost the router round trip, 1.22 ms against the kernel tunnel's 0.92 ms. The router run used a different traffic generator on each side, so read 122 against 66.8 as a result with that method attached.

For the ForestVPN-against-WireGuard matrix, use the compare page instead of this one.

The boundary: the Linux figures describe the Linux daemon on servers and virtual machines with the settings above. They say nothing about the phone, desktop or router apps, and the container run says nothing about ours.

Updated 2026-10-30: added the 2026-10-30 OpenVPN run; the 2026-10-16 figures are marked as the earlier build.

WireGuard or OpenVPN: which should you choose?

Choose by what the other end needs, not by a speed table.

A speed table from a different host does not carry to yours, and ours does not carry either.

Repeat the run on the machine that will do the work, with iperf3 and the same cipher on both sides if you want the protocols compared rather than the ciphers.

The protocol is also only one layer. The account model, how keys are handed out, what the app tells you when something fails and the kill switch matter as much on a day you are not benchmarking.