Legacy userspace OpenVPN benchmarks are why WireGuard built its speed reputation, but with Data Channel Offload, OpenVPN's data plane runs in-kernel too, and reaches parity or better: 700 Mbps vs. WireGuard's 600 Mbps in GL.iNet's own router tests, and roughly 2x throughput just from switching DCO on. Performance is no longer the deciding factor between the two — the real differences are in the other 12 dimensions (firewall traversal, authentication, post-quantum readiness, and so on).
If you're building a tunnel, those are the right numbers to care about.
If you're building access for people, they're close to irrelevant. And that's the distinction that trips up a lot of homelabs — because a homelab has a way of quietly turning into a multi-user system. You set up remote access for yourself. Then your partner wants to reach the Jellyfin server. Then a friend needs to get at the Minecraft box, and your brother-in-law wants to pull backups to his NAS, and somewhere in there you've stopped running a tunnel and started running an identity system.
This post is about the wall you hit when that happens, why it's a property of the protocol rather than a gap in your effort, and how to think about the trade-off honestly.
What WireGuard gets right
Let's be clear about this first, because the rest of the post is going to be about limitations and it would be easy to mistake that for a hatchet job.
WireGuard is excellent engineering. It runs in the Linux kernel, so it's fast in a way userspace tunnels struggle to match. Its codebase is small enough that a single person can audit it, which is a real security property and not just a talking point. Its cryptography is opinionated — one key exchange, one cipher, no negotiation — which eliminates an entire class of downgrade attacks that have historically plagued more flexible protocols. It's been formally verified. It's silent on the wire to unsolicited traffic. Setup for a single peer takes about four minutes.
For a point-to-point link between two machines you control, WireGuard is very often the correct answer, and we'd tell you so.
The trouble starts when the number of humans goes up.
The four-user setup that works perfectly well
Here's what small scale looks like in practice.
You generate a keypair for each person. You assign each of them an IP address out of your tunnel subnet — by hand, tracked in a text file or a spreadsheet, because WireGuard has no mechanism for handing out addresses. You paste each person's public key and their assigned IP into the server config, likely the Jellyfin server. You send each of them their private key and their config file, probably over email or a messaging app. You reload the server.
Four people. Maybe twenty minutes of work. Completely fine.
Now you add a fifth. Generate a key, pick an address that isn't taken, update the spreadsheet, SSH into the server, append the peer block, reload the config, send the key. Still fine — annoying, but fine.
Nothing about this is broken. It's the honest, intended way to run WireGuard, and for a lot of homelabs it never becomes a problem, because a lot of homelabs never get past five people.
The fortieth user
Scale it up and the same process stops being annoying and starts being a liability.
You have a spreadsheet of private keys. Somewhere in your notes app or your password manager or, realistically, your sent-mail folder, there is a plaintext record mapping devices to credentials. That's your access-control system.
You can't revoke anything cleanly. Someone leaves, or loses a laptop. You delete their peer block from the server and reload — fine, on that server. If you've got a second WireGuard endpoint, you do it again there. There's no revocation list, no expiry, nothing that propagates. If you miss a server, that key still works.
Keys never expire. The keypair you issued someone in 2022 is exactly as valid today as it was the day you made it. There's no lifetime, no forced rotation, no mechanism that makes stale credentials fail closed. Everything depends on you remembering.
Adding a second server means copying key material. Because there's no issuing authority, two WireGuard endpoints have no way to share a trust relationship. Either you copy the same server key onto both boxes — which is exactly as bad an idea as it sounds — or you maintain two entirely separate peer lists and tell your users which endpoint to connect to for what.
And you have no idea who anyone is. A WireGuard peer is a public key. It isn't a username, it isn't an email address, it doesn't carry a department or a role. Your logs show key fingerprints and IP addresses. Correlating those to actual people is, again, the spreadsheet.
This is a protocol limit, not an effort limit
Here's the part that matters, and it's the reason "just script it" doesn't get you out of this.
WireGuard authentication is a bare Curve25519 keypair. Not a certificate — a raw key. And a raw key is a very different object from a certificate, in ways that turn out to be load-bearing:
- A certificate has an expiry date. A bare key does not.
- A certificate is signed by an issuing authority, which means a server can trust a key it has never seen before, because it trusts whoever signed it. A bare key has to be individually pre-registered.
- A certificate carries an identity — a name, an email address, an organizational unit. A bare key carries nothing.
- A certificate can be revoked centrally, via a revocation list or OCSP. A bare key can only be removed from each config that references it.
You can build tooling around WireGuard to paper over some of this, and several projects do. But you're building a parallel system beside the VPN, not inside it, and the VPN has no idea your system exists. WireGuard's protocol is deliberately fixed — no extension mechanism, no negotiable options, no room for authentication headers. That rigidity is a genuine security feature. It's also a ceiling.
So when people say WireGuard "doesn't support" MFA or certificates, it isn't that nobody's implemented it yet. It's that the protocol has no place to put it.
What OpenVPN gets from TLS — and from its own protocol
OpenVPN took the opposite bet. Its key exchange comes from TLS, the same protocol securing most of the web, and that brings the entire X.509 certificate ecosystem with it.
Practically, that means you can issue every user a certificate signed by your own certificate authority. Your server holds the CA's public key and nothing else. Any certificate signed by that CA is trusted, which means you can add your fortieth user without touching the server at all. Add a second server, sign its certificate with the same CA, and both endpoints trust the same population of users automatically. Revoke a certificate centrally and it stops working everywhere.
If you already run Active Directory, or you've got a PKI for mutual TLS, or you keep certs on a hardware security module, OpenVPN plugs into what you have rather than asking you to build something new alongside it.
TLS also natively supports mutual authentication using X.509 client certificates, which is what lets a hardware token participate directly in the handshake. A YubiKey holding the certificate in its PIV slot means the private key never leaves the device, and your second factor becomes a physical object plus a PIN.
Separately — and this is a distinction worth getting right if you're comparing protocols properly — OpenVPN's own protocol carries an authentication channel alongside the tunnel. That's where the rest of it comes from:
- Usernames and passwords, on their own or layered on top of certificates
- TOTP two-factor, the six-digit codes from an authenticator app, handled through OpenVPN's challenge-response mechanism
- LDAP, RADIUS, and SAML, so your VPN authenticates against the identity system you already run instead of a separate user list
- Server-pushed configuration, meaning clients don't hold or manage their own routing and DNS settings — the server tells them at connect time, and you change it in one place
So it’s two layers doing two jobs: TLS handles identity you can prove with a certificate, and OpenVPN handles identity you assert with a credential. WireGuard has neither, because its protocol is fixed and has nowhere to carry either one.
That last bullet is quietly one of the biggest operational differences. With WireGuard, changing your DNS server means editing every client config. With OpenVPN, you change it on the server.
The post-quantum door
One more, and it's the clearest illustration of what "the protocol can't be extended" costs you over a long enough horizon.
Post-quantum key exchange — ML-KEM, the NIST-standardised lattice scheme — is being rolled into TLS now, as an additional group negotiated in the handshake. Because OpenVPN's key exchange is TLS, it can pick that up the same way any other TLS application does. IPsec is on the same path.
WireGuard cannot. Its key exchange is Curve25519, specified in the protocol, with no negotiation and no version field to hang an alternative off. Adding post-quantum key exchange to WireGuard means a new, incompatible protocol — not an upgrade.
Whether that matters to your homelab today is a fair question, and the honest answer is probably not. But if you're the kind of person who thinks about harvest-now-decrypt-later, it's worth knowing which of these two doors is open.
So which should you actually run?
Genuinely, it depends on the shape of the problem, not on which project has better engineering.
Run WireGuard when you're connecting machines rather than people. Site-to-site links, a handful of your own devices, containers phoning home, anything where you can automate provisioning and the peer list is stable. Its speed and simplicity are real advantages and there's no reason to give them up.
Run OpenVPN when the peer list is a list of humans who join and leave, when you need to prove who connected rather than which key connected, when someone's going to ask you for two-factor, or when "we should revoke that" needs to be a thirty-second job rather than an audit of every config file you own.
The crossover isn't a specific headcount. It's the moment you realize you're maintaining a spreadsheet of credentials — that's the signal that you've outgrown bare keys.
Doing it the OpenVPN way, free
Worth being explicit here, because there's a common assumption that certificates and MFA are the paid tier's problem.
They're not. Community-edition OpenVPN — the open-source project, no license, no account — supports all of it. Your own CA, certificate authentication, TOTP two-factor, hardware tokens, LDAP and RADIUS. If you want to build it yourself from config files and a couple of auth scripts, everything above is available to you today for nothing.
What you're trading is your time. Setting up TOTP on the community edition means writing an authentication script and handling challenge-response state yourself — we walked through exactly what that script looks like in a separate post, and it's more work than most people expect.
Access Server is a VPN and ZTNA solution that uses the OpenVPN protocol with those pieces and more already assembled behind a web UI, and it's free forever for two simultaneous connections — not a trial, no card, no expiry, and no features held back. For a homelab where one or two devices are connected at a time, that's frequently the whole requirement. Beyond two, you pay per concurrent connection.
Either path, whether that's the community edition or Access Server, gets you certificates and MFA. Pick the one that matches how you'd rather spend a Saturday.
Frequently asked questions
Is WireGuard faster than OpenVPN?
Not anymore. WireGuard's early lead was structural — it ran inside the Linux kernel while OpenVPN encrypted every packet in userspace — but Data Channel Offload moves OpenVPN's data channel into the kernel too. On the same machine, OpenVPN core developer Antonio Quartulli measured 3.61 Gbps without DCO and 7.15 Gbps with it, and on router hardware it now matches or beats WireGuard: 700 Mbps against 600 on a GL.iNet Mudi 7, identical on a Flint 3. You do need kernel 6.16 or newer and OpenVPN 2.6+ to get it, so check what your distribution actually shipped. For most homelabs it's academic anyway — a residential upload link runs out long before either protocol does.
Is WireGuard free?
Yes. WireGuard is free and open source under the GPLv2, with no paid tier and no commercial license requirement. OpenVPN's community edition is also free and open source. The paid product in this comparison is OpenVPN Access Server, which packages the same protocol with a management interface — and its first two simultaneous connections are free indefinitely.
Is WireGuard safe?
Yes. WireGuard's cryptography is modern, its implementation has been formally verified, and its small codebase makes it genuinely auditable. The limitations discussed in this post are about user management and authentication features, not about whether the encryption holds up — it does. A WireGuard tunnel is secure; it just can't tell you much about who's on the other end of it.
Does WireGuard support certificates?
No. WireGuard authenticates with bare Curve25519 public keys, which are not X.509 certificates. They have no expiry date, no issuing authority, no chain of trust, and no central revocation mechanism. This is a deliberate design decision that keeps the protocol simple, and it's the root of most of the multi-user limitations described above.
Does WireGuard support MFA or 2FA?
Not at the protocol level. WireGuard has no mechanism for usernames, passwords, TOTP codes, or hardware tokens — there's nowhere in the protocol to carry them. Third-party tools can add a login step alongside a WireGuard tunnel, but that authentication happens outside WireGuard and isn't covered by its security guarantees. OpenVPN handles MFA inside the protocol itself.
Does WireGuard use UDP or TCP?
UDP only, on a single configurable port. It cannot fall back to TCP. This matters on restrictive networks — hotel Wi-Fi, corporate guest networks, some mobile carriers — that block or throttle unfamiliar UDP traffic. OpenVPN can run over TCP on port 443, where it's difficult to distinguish from ordinary HTTPS, which is often the difference between connecting and not connecting.
Can WireGuard be blocked?
Yes, fairly easily. Its handshake has a recognizable signature, and because it's UDP-only on a fixed port, it's straightforward to filter with deep packet inspection or a blanket UDP block. OpenVPN over TCP 443 is considerably harder to block without also breaking normal web browsing.
Does WireGuard support post-quantum encryption?
No, and you can't add it without creating a new protocol. WireGuard's key exchange is fixed at Curve25519 with no negotiation mechanism. OpenVPN inherits its key exchange from TLS, so it can adopt post-quantum groups such as ML-KEM through the same path as the rest of the TLS ecosystem.