WireGuard and OpenVPN are the two protocols you'll find in almost every VPN app's settings
screen. Pick either one and your traffic gets encrypted, your ISP loses visibility into what
you're doing, and your IP gets hidden from the sites you visit. That part's not really in
question.
What differs is speed, how each one handles your IP address inside the tunnel itself, and how
easily a firewall can spot and block them. This article starts with the basics, then gets into
the parts that actually change which one you should pick.
What is WireGuard?
WireGuard is a VPN protocol released in 2015 by developer Jason Donenfeld, and it got merged directly into the Linux kernel in 2020, a fairly rare vote of confidence for a piece of networking software that young. The goal from day one was to be small and easy to review. Most older VPN protocols grew over decades of patches, added features, and compatibility fixes. WireGuard was mostly written from scratch, aimed at doing one job (build an encrypted tunnel) without much else attached to it.
What is OpenVPN?
OpenVPN has been around since 2001, which makes it almost ancient by internet standards. It's not built into any operating system by default, so you install a client, and that client sets up an encrypted tunnel using roughly the same handshake process your browser uses when it connects to your bank's website (TLS). OpenVPN can run over UDP or TCP, on nearly any port you configure it for. That flexibility is the whole reason it's stuck around this long.
Quick summary: which one to pick
If you don't need the full breakdown, here's the short version.
- You want the fastest, lowest-latency connection available
- Battery life matters — you're on a phone or laptop most of the day
- You switch networks often (Wi-Fi to mobile data) and want the tunnel to survive it
- You're not trying to hide the fact that you're using a VPN at all
- You're on a network actively trying to detect and block VPN traffic
- You need to run over TCP port 443 to blend in with normal HTTPS traffic
- Your router or firewall only supports older, more established protocols
- Stability under a flaky connection matters more than raw speed
Cryptography and codebase size
WireGuard's implementation is small. Depending on what you count, it's commonly cited at under 4,000 lines of code, growing to around 7,000 once you include the full transport and platform layers. OpenVPN runs closer to 70,000 lines, and it leans on OpenSSL for its actual encryption work, which is a separate, much larger codebase with its own history of bugs (Heartbleed being the one everyone remembers). IPsec, the older enterprise standard both get compared against, is bigger still. Some estimates put it near 400,000 lines.
Smaller isn't just tidier. It's fewer places for a mistake to hide. That's really the whole security argument for WireGuard, and it's why cryptographers took it seriously well before it had OpenVPN's two-decade track record.
On the actual cryptography: WireGuard uses one fixed set of tools and doesn't let you swap them out. Curve25519 handles the key exchange (the math two devices use to agree on a shared secret without anyone listening in being able to work it out). ChaCha20-Poly1305 does the actual encryption. BLAKE2s handles hashing. No negotiation, no fallback to an older cipher if something goes wrong. Sounds restrictive, until you remember that cipher negotiation is exactly where a lot of real-world TLS vulnerabilities have lived over the years. OpenVPN, by contrast, supports a wider menu of options, including AES-256 in both its GCM and older CBC modes, mostly to stay compatible with two decades of existing setups. Useful in enterprise contexts. Mostly irrelevant if you're just using a consumer VPN app.
WireGuard's static IP address issue
Here's a detail that sounds boring until you understand why it matters. WireGuard was built as a general-purpose tunneling protocol, not specifically for anonymous commercial VPN services, and its designers left dynamic IP assignment out of the protocol on purpose to keep things small. OpenVPN and IKEv2 both hand you a fresh internal tunnel IP every time you connect, the same way your home router hands out a new address when a device joins the Wi-Fi. WireGuard doesn't do that by default. Each device gets a fixed internal IP tied to its key, and that IP stays the same until the key changes.
On its own, nobody would ever notice this. It only becomes a problem if that internal address leaks somehow, most commonly through a WebRTC leak in your browser, since browsers can expose local network addresses to any site that asks. A leaked static internal IP, seen across multiple sessions, works as a fingerprint. It can tie separate connections back to the same device even while your actual public IP stays hidden. Our IP leak test and DNS leak test check for exactly this kind of exposure regardless of which protocol you're running.
A researcher going by tmctmt found that Mullvad's exit-IP assignment for WireGuard connections wasn't fully random. It was tied to a user's WireGuard key in a way that let patterns of server-switching be traced back to one device with high confidence. Mullvad confirmed part of the behavior was intentional and part wasn't, and pointed to the fix that already existed: regenerating your WireGuard key, which also resets your internal IP.
This doesn't mean WireGuard is broken. It means the protocol left a gap for VPN providers to fill in themselves, and not every provider has actually done it. Some have: IVPN assigns a random tunnel IP per key instead of a predictable one, Mullvad and OVPN let you rotate your key (and IP) with one click, and NordVPN built its NordLynx protocol around a system specifically designed to sidestep this issue. If a provider's documentation never mentions any of this, it's usually because they haven't dealt with it, not because it doesn't apply to them.
Bypassing firewalls and censorship
Deep packet inspection, DPI for short, is when a network operator (an ISP, a government, a corporate IT department) looks at the actual shape and pattern of your traffic, not just where it's headed. This is where OpenVPN, despite its age, still has a real advantage in one specific scenario: hostile networks.
A WireGuard handshake has a fixed, near-constant size (the initiation packet lands around 148 bytes, the response around 92) and it runs over UDP by default. That's an easy pattern for DPI to flag with a basic rule: UDP packet, known header, predictable size, block it. This is a documented reason plain WireGuard traffic gets blocked in countries running aggressive internet filtering.
OpenVPN's edge here has nothing to do with stronger encryption. It's just better disguised. Configured to run over TCP on port 443, OpenVPN traffic looks, at a casual glance, like any other HTTPS connection to a website. That one configuration option has made it the go-to recommendation for years in places where a VPN needs to blend in rather than announce itself.
That gap is closing, though not by WireGuard changing itself. A whole ecosystem of obfuscation tools has grown up around it instead. AmneziaWG, a WireGuard fork maintained by the Amnezia VPN team, adds decoy packets before the real handshake and randomizes packet sizes specifically to beat this kind of fingerprinting. A lighter-weight open-source tool called wg-obfuscator does something similar without forking WireGuard at all. NordVPN went further with a separate protocol, NordWhisper, built to mimic normal web traffic from the ground up rather than disguise WireGuard's signature after the fact. None of this is part of vanilla WireGuard, though. It's either something your provider built, or something you'd have to set up yourself — our VPN reviews note which providers ship their own obfuscation layer.
Performance, roaming, and battery life
WireGuard's statelessness (the same design choice behind the IP issue above) is also what makes it good at surviving network changes. Walk out of a coffee shop's Wi-Fi and onto mobile data mid-download, and a decent WireGuard client reconnects almost instantly, because it doesn't need to renegotiate a full session the way OpenVPN does. Add a much smaller codebase that's easier to run efficiently at the kernel level, and WireGuard consistently comes out faster and lighter on battery in independent mobile testing.
OpenVPN's weak spot shows up specifically when it's forced onto TCP under bad network conditions. Running one reliable protocol (TCP) inside another reliable protocol (the outer TCP connection carrying your traffic) creates a known problem sometimes called TCP meltdown: retransmissions stack up and the whole thing can grind to a crawl under packet loss. OpenVPN's UDP mode mostly avoids this and performs closer to WireGuard. But UDP mode is also the easiest one for a firewall to spot and block, which is the trade-off in a sentence.
Side-by-side comparison
| Property | WireGuard | OpenVPN |
|---|---|---|
| Released | 2015 | 2001 |
| Codebase size | ~4,000–7,000 lines | ~70,000+ lines (plus OpenSSL) |
| Key exchange | Curve25519 (Noise_IK) | TLS handshake (RSA/ECDHE) |
| Encryption | ChaCha20-Poly1305 (fixed) | AES-256-GCM/CBC (negotiable) |
| Transport | UDP only | UDP or TCP |
| Port 443 / HTTPS camouflage | Not natively — needs an obfuscation layer | Native, via TCP mode |
| Internal IP assignment | Static per key, by default | Dynamic per session |
| Network roaming | Near-instant reconnect | Full renegotiation required |
| Typical speed loss vs. raw connection | ~5–10% | ~15–30% |
Whichever protocol you land on, it's worth confirming the tunnel is actually doing its job. If you want the full picture on which providers handle WireGuard's IP quirks well, see our best VPNs in 2026 guide. If you're deciding between a free and paid option in the first place, our free vs. paid VPN breakdown covers the trade-offs that matter more than protocol choice.
Confirm your VPN isn't leaking
Protocol choice doesn't matter much if the tunnel itself is leaking your real IP or DNS requests. Run our free tests to check.