WireGuard vs OpenVPN
WireGuard vs OpenVPN compared on design, performance, transport, authentication, pushed config, platforms and maintenance, using OpenVPN 2.7.8 and WireGuard's in-kernel implementation as of October 2026.
Quick Answer
Pick WireGuard for site-to-site links, homelab access and server meshes you configure yourself: it is a small, fixed-crypto UDP tunnel built into Linux since kernel 5.6, it roams across IP changes without reconnecting, and a peer is just a public key and a list of allowed IPs. Pick OpenVPN when you need what WireGuard leaves out on purpose: TCP transport (including sharing port 443 with an HTTPS server), certificate-based PKI, username and password checks through scripts or plugins, server-pushed routes and DNS, or layer 2 (TAP) bridging. OpenVPN 2.7 (current: 2.7.8, 7 Oct 2026) narrows the speed gap with kernel data channel offload, but DCO drops TAP and compression.
Last updated October 28, 2026. Covers OpenVPN 2.7.8 (7 Oct 2026) and 2.6.23 (23 Sep 2026), the DCO feature table, OpenVPN 2.7 changes and Access Server pricing, and WireGuard's documentation and wireguard-tools v1.0.20260223, as of 28 Oct 2026.
| Feature | WireGuard | OpenVPN |
|---|---|---|
| Licence | GPLv2 (kernel); tools and apps MIT, BSD, Apache-2.0 or GPL | GPLv2 with OpenSSL and Apache-2.0 linking exceptions |
| Latest Release (Oct 2026) | In mainline Linux since 5.6; wireguard-tools v1.0.20260223 | 2.7.8 (7 Oct 2026); 2.6.23 old-stable (23 Sep 2026) |
| Where It Runs | Linux kernel module; wireguard-go userspace on macOS/BSD; native apps | Userspace daemon; optional kernel DCO on Linux, Windows, FreeBSD |
| Transport | UDP only | UDP or TCP (with TCP port sharing) |
| Cryptography | Fixed: Noise, Curve25519, ChaCha20-Poly1305, BLAKE2, SipHash24, HKDF | TLS control channel; AES-GCM or ChaCha20-Poly1305 data channel |
| Authentication | Per-peer public keys, optional pre-shared key | Certificates, peer fingerprints, username/password via scripts and plugins |
| Server-Pushed Config | No (out of scope) | Yes (--push routes, DNS, options) |
| Layer 2 (TAP) Bridging | No (layer 3 only) | Yes (dev tap), not with DCO |
| Multi-User Server | None built in; one [Peer] per device | Server mode, per-client config, plugins |
| Roaming / IP Changes | Built in on both ends | --float; DCO client-float support in 2.7 |
| Platforms | Linux, Windows 10/11 and Server 2016-2025, macOS, iOS, Android, FreeBSD, OpenBSD | Linux, BSD, macOS, Windows 10/11 |
| Commercial Edition | None from the project | Access Server: free for 2 connections, then $7/connection/month billed yearly |
WireGuard
A layer 3 VPN tunnel by Jason A. Donenfeld that encapsulates IP packets over UDP using a fixed set of modern primitives (Noise, Curve25519, ChaCha20, Poly1305, BLAKE2). It runs as a Linux kernel network interface (wg0) configured with wg(8) and wg-quick(8), with cross-platform implementations for Windows, macOS, BSD, iOS and Android.
Pros
- Built into the Linux kernel since 5.6; older kernels can use backport or DKMS modules, per the install page
- Configuration is a private key plus one [Peer] block per peer with a public key and AllowedIPs, much like exchanging SSH keys
- Cryptokey routing ties tunnel IPs to public keys, so a packet from a peer using an IP it is not allowed is dropped
- Full roaming on both ends: peers follow the most recent authenticated source address without renegotiating
- Silent to unauthenticated packets, and the protocol has a symbolic proof in Tamarin plus computational proofs listed on the formal-verification page
- A WireGuard interface can be moved into a container's network namespace so the tunnel is that container's only route out
Cons
- UDP only by design; getting through TCP-only networks needs an extra layer such as udp2raw or udptunnel
- No obfuscation, so deep packet inspection can identify and block it
- Key distribution, user accounts and pushed configuration are out of scope; you script them or use a tool built on top
- No cipher negotiation and no post-quantum handshake by default (a pre-shared key adds a post-quantum layer, per the known-limitations page)
- Layer 3 only: no Ethernet bridging
Best For
Site-to-site links, homelab and VPS access, server-to-server meshes and container egress where you control both ends and UDP is allowed.
OpenVPN
The long-standing open-source VPN daemon from OpenVPN Inc. and its community. It uses a TLS control channel (OpenSSL or mbedTLS) to authenticate peers and negotiate keys, carries traffic over UDP or TCP on tun or tap devices, and supports server mode for many clients, pushed options, scripts and plugins. OpenVPN Inc. also sells Access Server and CloudConnexa.
Pros
- Runs over UDP or TCP, and --port-share lets a TCP server share its port with an HTTPS server, which helps on networks that only allow 443
- Flexible authentication: X.509 certificates, --peer-fingerprint for small setups without a CA, and username/password checks through --auth-user-pass-verify scripts or plugins
- Server mode pushes routes, DNS and other options to clients, with per-client overrides via --client-config-dir
- Supports layer 2 bridging with dev tap, which WireGuard cannot do
- OpenVPN 2.7 adds multi-socket servers (UDP and TCP at once), split-DNS handling on Linux, BSD, macOS and Windows, and kernel data channel offload for servers on Windows
- Clear support policy: 2.7 has full support, 2.6 old-stable with security fixes until at least August 2027
Cons
- More moving parts: a PKI or fingerprints, TLS settings, a server config and client profiles before the first packet flows
- Without DCO the data channel runs in userspace; WireGuard's own site calls OpenVPN 'extremely slow' in its (self-described old) benchmarks
- DCO does not support TAP mode, compression or --fragment, and some options make OpenVPN fall back to the regular tun driver
- Frequent security releases: 2.7.5 to 2.7.8 shipped between July and October 2026, each with CVE fixes
- 2.7 removed static-key (--secret) mode by default, compression on send and the wintun driver, which can break old configs on upgrade
Best For
Remote-access VPNs for many users that need certificates or password auth, pushed routes and DNS, TCP/443 fallback through restrictive firewalls, or layer 2 bridging.
Design: a fixed tunnel interface versus a TLS-based daemon
WireGuard is deliberately small. You add an interface such as wg0, give it a private key and a list of peers, and each peer has a public key, a set of AllowedIPs and optionally an endpoint. Outgoing packets are matched to a peer by destination IP and encrypted to that peer's key; incoming packets are accepted only if they decrypt for a peer and their inner source IP is in that peer's AllowedIPs. The project calls this cryptokey routing. The crypto suite is fixed: Noise for the handshake, Curve25519, ChaCha20-Poly1305, BLAKE2, SipHash24 and HKDF. There is no negotiation, which removes downgrade problems but means a future change would be a new protocol version. Everything about distributing keys or pushing settings is explicitly out of scope, the homepage says, to avoid the bloat of IKE or OpenVPN. OpenVPN is a userspace daemon with a TLS control channel. Peers authenticate with certificates (or, in 2.7, --peer-fingerprint), negotiate data-channel keys, and then exchange packets over UDP or TCP on a tun or tap device. A server process handles many clients, pushes options to them and can call scripts and plugins at connect time. That flexibility is the reason OpenVPN still runs a lot of corporate remote access, and it is also the reason its configuration surface and codebase are much larger.
Performance: kernel WireGuard versus OpenVPN with and without DCO
WireGuard's speed comes from two things: ChaCha20-Poly1305 is fast in software on almost any CPU, and on Linux the whole data path lives in the kernel. The WireGuard site still shows an older benchmark against IPsec and OpenVPN and labels it 'old, crusty, and not super well conducted', adding that OpenVPN 'remains extremely slow'. Treat that as the project's own claim, not a current measurement. Classic OpenVPN moves every data packet between kernel and userspace for encryption and routing, which costs throughput and CPU. Data Channel Offload changes that by moving the data channel into a kernel module: ovpn on Linux (the new upstream module, which the OpenVPN wiki says was merged on its way to Linux 6.16), win-dco on Windows and a FreeBSD module. OpenVPN 2.7 supports only the new Linux API, adds DCO server mode on Windows and lets kernel modules report clients floating to a new IP. If DCO is compiled in, OpenVPN uses it automatically unless an option is incompatible; --disable-dco turns it off. The catch is the DCO feature table: TAP mode, compression and OpenVPN's own --fragment are not supported and not planned, TCP transport is not available on FreeBSD or for Windows servers, and --reneg-bytes and --reneg-packets do not work. Plan your config around those before expecting DCO numbers.
Getting through restrictive networks: UDP-only versus TCP and port 443
WireGuard only speaks UDP. Its known-limitations page explains why: tunnelling TCP over TCP performs badly, so turning WireGuard's UDP packets into TCP is left to tools such as udp2raw or udptunnel. It also does not try to hide itself from deep packet inspection; obfuscation is meant to sit in a layer above. On a hotel or corporate network that blocks outbound UDP, or a censor that fingerprints the handshake, plain WireGuard will not connect. OpenVPN handles this natively. --proto accepts udp, tcp-client or tcp-server (with 4 and 6 variants), and --port-share lets an OpenVPN TCP server on port 443 hand non-OpenVPN connections to a real HTTPS server on another port. 2.7 adds multi-socket support, so one server can listen on UDP and TCP at the same time. It is not invisible to DPI either, but TCP on 443 gets through far more firewalls than UDP on 51820. The practical pattern on a VPS is to run WireGuard for your own devices on networks you trust and keep an OpenVPN TCP listener, or a WireGuard-over-TCP wrapper, as the fallback for the networks that block UDP. NAT is handled differently too: WireGuard peers behind NAT set PersistentKeepalive (the quick start suggests 25 seconds) to keep mappings alive.
Users, PKI and pushed config: what you have to build yourself
With WireGuard, every client is a [Peer] block on the server with its own key pair and tunnel IP. Adding a user means generating keys, choosing an address, editing the server config (or running wg set) and getting a client config to the device, often as a QR code for the mobile apps. There is no username or password, no certificate revocation list and no way for the server to push DNS or routes; the client config carries them. That is fine for ten devices you own and tedious for two hundred employees, which is why tools built on WireGuard add a control plane. OpenVPN has these pieces in the box. A server in --mode server handles many clients over one tun or tap interface, --push sends routes, DNS and other options (scripts are blocked from being pushed for safety), --client-config-dir applies per-client settings, and --auth-user-pass-verify or a plugin can check usernames and passwords against your own system. Certificates give you revocation and expiry. 2.7 also improves the client side: Linux, BSD and macOS builds ship a default --dns-updown script for split DNS, and Windows uses NRPT. If you want this without managing it, OpenVPN Inc. sells Access Server, which its pricing page lists as free for up to 2 simultaneous connections and $7 per connection per month on yearly billing beyond that, with DCO included on every plan.
Maintenance in 2026: releases, security fixes and breaking changes
WireGuard on Linux updates with your kernel, so there is rarely a separate VPN release to track; the userspace tools move slowly (the latest wireguard-tools tag is v1.0.20260223). The site copyright and some pages are dated, but the protocol is stable by design, and that stability is part of the appeal. OpenVPN has a busier release train. The community wiki lists 2.7 (first released 11 Feb 2026) as the current stable branch with full support, and 2.6 as old-stable with security and critical fixes until at least August 2027 and git-tree-only updates to at least August 2028. Since July 2026 the project has shipped 2.7.5, 2.7.6, 2.7.7 and 2.7.8, each with security fixes (use-after-free and reliability-layer bugs, Windows service issues, and in 2.7.8 rejecting certificates with NUL bytes in the subject). That is a healthy response rate, and also a reminder that a larger TLS-based codebase needs patching discipline. Upgrading to 2.7 can break old configs: static-key --secret mode is disabled by default (to be removed in 2.8), compression on send is gone, wintun support is dropped on Windows, OpenSSL 1.0.2 and mbedTLS 2.x are no longer supported, and NTLMv1 proxy auth is removed. Test client profiles before you roll it out.
Verdict
Choose WireGuard when you control both ends and UDP gets through: linking a VPS to your home network, meshing a few servers, giving yourself and a handful of devices access to a private subnet, or forcing a container's traffic through a tunnel. Configuration is a key pair and a short list of peers, it is in the Linux kernel, it survives IP changes without a reconnect, and the protocol has formal proofs behind it. Choose OpenVPN when the problem is users and networks rather than links: you need certificates or username and password checks against an existing system, routes and DNS pushed from the server, a TCP fallback that can share port 443 with a web server, or layer 2 bridging. If speed is the worry with OpenVPN, run 2.7 with data channel offload, but check the DCO feature table first: TAP, compression and --fragment are not supported there. If you want WireGuard's data plane with user management, put a coordination layer on top (see our NetBird vs Tailscale comparison) rather than switching to OpenVPN for that alone.