Quick answer

941 Mbps through one WireGuard tunnel on a Netgate 4100 at 14W, from a kernel implementation of roughly 4,000 lines against OpenVPN’s ~70,000. Run WireGuard by default for homelab remote access. Keep OpenVPN for the one case it still owns: UDP-blocked networks, where TCP on port 443 passes as ordinary HTTPS.

If you’re comparing WireGuard and OpenVPN, most of what you’ll find is written for commercial VPN shoppers — which provider’s app is faster, which unblocks more streaming. This is the other version of the question: you’re a self-hoster putting a VPN server on your own router, Raspberry Pi, or Proxmox container so you can reach your homelab from anywhere (and maybe link two sites). For that job, the 2026 answer is direct: WireGuard is the default, and OpenVPN survives for exactly one scenario — networks where UDP is blocked and only TCP on port 443 gets out. The rest of this guide is the evidence, the benchmarks from our own hardware, and the configurations where each one earns its place.

(If your actual question is “WireGuard or Tailscale,” that’s a different comparison — Tailscale is WireGuard plus a coordination layer. This article is about the raw protocols you host yourself.)

Protocol architecture: what you’re actually running

WireGuard lives in the Linux kernel (mainlined in 5.6, 2020) and is famously small — about 4,000 lines of code in the original kernel implementation, per its NDSS 2017 academic paper. Its cryptography is fixed, not negotiated: ChaCha20-Poly1305 for authenticated encryption, Curve25519 for key exchange, BLAKE2s for hashing, HKDF for key derivation, in a Noise IKpsk2 handshake — all specified on the official protocol page. Identity is just a key pair, like SSH. It is UDP-only by design (the project explicitly avoids TCP tunneling because TCP-over-TCP degrades badly), and it roams beautifully: when your phone hops from WiFi to LTE, the server just starts replying to the new address — no re-key, no reconnect dance.

OpenVPN is the two-decade veteran: a userspace daemon built on TLS via OpenSSL, with negotiated ciphers (AES-256-GCM is typical; ChaCha20-Poly1305 is available in modern builds), a full PKI — CA certificate, server certificate, client certificates — and both UDP and TCP modes. The codebase is roughly 70,000 lines, an order of magnitude larger than WireGuard. That heft buys flexibility: cipher policy compliance, user/password auth options, and the single killer feature WireGuard deliberately lacks — TCP on port 443, where VPN traffic is effectively indistinguishable from ordinary HTTPS at the packet-inspection layer.

Performance: the honest picture on homelab hardware

TestWireGuardOpenVPNSource
Netgate 4100, single tunnel941 Mbpsnot benchedour own firewall stack bench
GL.iNet Flint 2 (OpenWrt)~900 Mbpsnot benchedindependent reviews, per our gear guide
PIA vendor test (US)~180 Mbps~120 Mbpsvendor-conducted, conditions undisclosed
ExpressVPN latency (UK, same server)40 ms113 ms (TCP)vendor-conducted

The honest framing: the “3–4x faster” claim that circulates comes from vendor tests and old benchmarks — WireGuard’s own performance page openly calls its published numbers “old, crusty, and not super well conducted,” and critics have noted the original whitepaper benchmarks used 64KB jumbo frames rather than real ~1500-byte internet packets. The defensible version: on Linux, WireGuard’s kernel-space path gives it a real CPU-efficiency edge (roughly 1.3–1.5x in comparable tests, and much lower latency than OpenVPN-over-TCP), while on Windows and macOS it runs in userspace (wireguard-go) and the gap narrows. For a homelab, both protocols are faster than your WAN link. A modest firewall appliance pushes WireGuard at wire speed — 941 Mbps on our Netgate 4100 at 14W. The protocol is not your bottleneck; pick on traversal, config complexity, and use case instead.

The comparison table

WireGuardOpenVPN
TransportUDP onlyUDP or TCP (incl. port 443)
Blocked-network traversalFails if UDP filtered (needs a wrapper)TCP/443 passes almost everything
CryptoFixed modern suite (ChaCha20-Poly1305, Curve25519)Negotiated via OpenSSL (agile, misconfigurable)
Codebase~4,000 lines (kernel implementation)~70,000 lines
Security reviewFormal verifications (Tamarin, eCK/ACCE, ProVerif, verified Curve25519)Two decades of production use + independent audits
SetupKey pair + a dozen config lines per peerFull PKI: CA, server cert, client certs, config
Roaming (WiFi ↔ LTE)Automatic, no reconnectReconnect required
Site-to-siteSymmetric peer configServer/client model, more moving parts
Kernel-space (Linux)YesNo (userspace + tun driver)
DPI visibilityIdentifiable as WireGuardTCP/443 mode blends with HTTPS

Road-warrior: reaching your homelab from anywhere

This is the case most self-hosters actually have — laptop or phone out in the world, homelab at home.

  • WireGuard wins every normal network: home WiFi, coffee shops, cellular. Sub-second connections, silent roaming, a battery-friendly protocol, and clients on every platform. Our WireGuard-on-Proxmox guide gets a road-warrior server running in an afternoon.
  • OpenVPN wins the hostile networks: corporate offices that block outbound UDP, hotel and airport captive portals, ISPs that filter VPN traffic. OpenVPN in TCP mode on port 443 looks like HTTPS and gets through.
  • The simple test: from the restrictive network, check whether you can reach your home IP on UDP 51820. Reachable → WireGuard. Blocked → OpenVPN TCP/443 (or a TCP wrapper like wstunnel around WireGuard, if you’d rather carry the complexity than run a second server).

Our own setup, documented in the firewall stack article, is the honest real-world answer: WireGuard for road-warrior duty, with a small OpenVPN TCP-443 instance kept alive as the fallback for the two situations a year where UDP dies. On OPNsense or pfSense, running both side by side is a couple of tabs in the same UI (OPNsense VPN docs cover both first-class).

Site-to-site: linking two networks

Connecting your home network to a VPS, a parent’s house, or a second site changes the calculus slightly:

  • WireGuard does site-to-site with a pleasingly symmetric config — each side lists the other as a peer, AllowedIPs carries the remote subnet, IP forwarding on, done (worked reference config). The catch: at least one side needs a reachable endpoint (public IP or port forward); WireGuard has no built-in relay for two-sides-behind-CGNAT (that’s the problem Tailscale exists to solve).
  • OpenVPN uses a server/client model for site-to-site, with the extra PKI ceremony that entails — but inherits its TCP fallback, which matters if one site sits behind a UDP-hostile ISP.

Default to WireGuard here too; reach for OpenVPN when one end’s network conditions demand TCP.

What about the criticisms of WireGuard?

Two are worth taking seriously. No cipher agility: if ChaCha20 or Curve25519 is ever weakened, every WireGuard endpoint must upgrade in lockstep — a legitimate enterprise objection that is mostly moot in a homelab where you control all five endpoints. No obfuscation and UDP-only: covered above; that’s precisely OpenVPN’s remaining lane. The security fundamentals, meanwhile, are unusually strong — WireGuard’s protocol carries multiple published formal verifications (symbolic and computational proofs plus formally verified crypto implementations), a level of analysis very few network protocols get. OpenVPN counters with something different but real: twenty years of production hardening and independent audit history.

Bottom line

Run WireGuard. It’s in the kernel, it’s a dozen lines of config, it roams silently, it’s formally verified, and it moves at wire speed on a $60 router — while you’ll hit your WAN cap long before you hit the protocol’s. Keep OpenVPN in your toolkit for the one thing it still does better than anything: escaping UDP-hostile networks over TCP 443, either as a standing fallback server (our setup) or spun up when a work trip demands it. And if what you actually want is WireGuard without thinking about keys and endpoints, that’s Tailscale’s job — a different trade, covered in a different comparison.

Frequently asked questions

What are the disadvantages of WireGuard?
Four real ones, straight from the project’s own known-limitations page. It is UDP-only - on a network that blocks or throttles UDP, WireGuard simply does not connect without a TCP wrapper like wstunnel or udp2raw. It makes no attempt at obfuscation, so deep packet inspection can identify the handshake as WireGuard. Its cipher suite is fixed - there is no negotiating a different algorithm, which enterprises with cipher policies dislike (though for a homelab where you control every endpoint, this is actually a simplification, not a problem). And it has no built-in user/password auth or certificate infrastructure - identity is a key pair, and anything fancier is your job.
Can WireGuard be detected?
Yes. WireGuard deliberately does not do obfuscation - its handshake packets have an identifiable structure, so a firewall doing deep packet inspection can recognize and block it. The project’s own known-limitations page is explicit about this. OpenVPN running in TCP mode on port 443 is the classic answer for restrictive networks, since it is difficult to distinguish from ordinary HTTPS traffic at the packet level. If you only occasionally face such networks, wrapping WireGuard in a TCP tunnel works too, at a complexity and performance cost.
Is WireGuard still safe in 2026?
Yes - it remains one of the most heavily analyzed VPN protocols in existence. Its protocol has multiple published formal verifications: a Tamarin symbolic proof covering key agreement, authenticity, and forward secrecy, computational proofs (eCK and ACCE models), a ProVerif analysis of its Noise IK handshake, and formally verified Curve25519 implementations (HACL*, Fiat-Crypto) - all catalogued on wireguard.com’s formal-verification page. Its small codebase (about 4,000 lines in the original Linux kernel implementation, per the NDSS 2017 paper) is the design decision that makes that level of review possible. Standard caveats apply: keep endpoints updated, protect private keys, and use the optional preshared key if post-quantum resistance matters to you.
Which is safer, WireGuard or OpenVPN?
Both are considered secure when configured correctly - the difference is how they get there. WireGuard’s security case rests on a tiny, formally verified protocol with fixed modern ciphers: there is almost nothing to misconfigure. OpenVPN’s rests on two decades of production hardening and independent audits, built on OpenSSL - which brings cipher agility, and with it the possibility of weak configurations. For a self-hoster, the practical answer: a default WireGuard setup is harder to get wrong; a well-configured OpenVPN setup is equally trustworthy but has more knobs that must be set correctly.
Should I use WireGuard or OpenVPN for my home server?
WireGuard, unless you regularly connect from networks that block UDP. It is in the Linux kernel (since 5.6), configures in a dozen lines per peer, switches between WiFi and cellular without dropping the tunnel, and runs at wire speed on modest router hardware - we measured 941 Mbps through a single tunnel on a Netgate 4100. Choose OpenVPN specifically when you need TCP port 443 to get out of corporate offices, hotels, or captive portals. Many homelabbers - us included - run WireGuard as the primary and keep a small OpenVPN TCP-443 instance as the fallback for exactly those networks.

Evidence ledger

Last updated
Methodology
This networking guide was written and edited by Lowell K. Wood IV in St. Louis County, MO. Specs and prices verified against vendor and project documentation current on the date above. Full editorial standard: methodology.
Update log
  • 2026-08-15 — Last reviewed and updated.
Corrections
Spotted an error or a stale number? Email hello@techfuelhq.com. Confirmed corrections are added to the update log above.

About the author

Written by Lowell K. Wood IV, who builds and runs TechFuelHQ from St. Louis, Missouri.