WireGuard: The VPN That Embarrassed the Entire Industry by Being 4,000 Lines of Code

Let's talk about the most diplomatically named piece of software in the Linux kernel. WireGuard's official description is "fast, modern, secure VPN tunnel." What that description is too polite to mention is that it was written by a single researcher, Jason Donenfeld, presented at a security conference in 2017, and merged into the Linux mainline in 2020 after Linus Torvalds personally lobbied for it on the kernel mailing list. It replaced protocols that entire companies had spent decades building. It did it in fewer than 4,000 lines of code.

For context: OpenVPN plus its OpenSSL dependency runs to roughly 600,000 lines. A popular IPSec implementation, OpenSwan, contains more than 8 megabytes of source code in multiple languages. WireGuard is smaller than both of those by a factor that makes the comparison feel like a category error.

Here's the uncomfortable question those numbers raise. If WireGuard can provide a secure, performant, roaming-capable VPN tunnel in 4,000 lines, what exactly were the other 596,000 lines doing?

Mostly, it turns out, managing complexity that those protocols created for themselves.

Let's get into it.

The Problem with IPSec, or Why "Flexible" Is a Four-Letter Word

We covered IPSec's sprawl in an earlier piece on SD-WAN. The short version: IPSec is not a protocol. It is a framework for negotiating between protocols, and it has been accumulating negotiable surface area since 1995. You can pick your key exchange (IKEv1 or IKEv2), your authentication method (pre-shared keys, RSA certificates, ECDSA certificates), your encryption algorithm (AES-128, AES-256, ChaCha20, 3DES if you enjoy suffering), your integrity algorithm (HMAC-SHA1, HMAC-SHA256, SHA-384, SHA-512), your Diffie-Hellman group (fourteen standard groups, more if you want), your mode (transport or tunnel), and your lifetime before rekeying. All of this is negotiated at connection time over IKE, a separate sub-protocol with its own state machine and its own attack surface.

The argument for this flexibility has always been that different use cases need different algorithms. That argument sounds reasonable until you think about it for thirty seconds. The actual outcome of cipher agility is that you end up with legacy ciphers that no one has removed because someone somewhere claims to need them, misconfigured deployments using 3DES because an administrator picked the wrong menu option, and downgrade attacks where an adversary forces both peers to negotiate the weakest cipher both sides support. TLS spent about fifteen years proving this empirically, through BEAST, POODLE, FREAK, Logjam, and a parade of vulnerabilities whose common thread was that the negotiation machinery itself was the attack surface, not the underlying ciphers.

Jason Donenfeld read that history and came to a simple conclusion. Cipher agility is not a feature. It is a liability that the industry has been carrying so long it forgot the debt was there.

WireGuard has no cipher negotiation. You get Curve25519 for the key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing, SipHash24 for hash table protection, and HKDF for key derivation. That is it. Those choices are baked into the protocol specification. If you want to run something else, you are not running WireGuard.

This is the design decision that security auditors love and enterprise architects have panic attacks about. We'll get to both reactions, because both are correct.

The Cryptographic Stack, or Opinions as a Service

The five primitives WireGuard chose deserve individual attention, because they were not chosen arbitrarily, and understanding why they were chosen tells you a lot about the threat model.

Curve25519. This is Daniel Bernstein's elliptic curve, designed in 2006 for Diffie-Hellman key exchange. It operates on the 255-bit prime field given by 2^255 minus 19 (hence the name), and it was specifically designed to be fast, safe to implement, and resistant to timing side channels. The design avoids the implementation hazards that plagued NIST curves, which historically required careful constant-time implementations to avoid leaking private key material. Curve25519 is the same curve used in Signal, WhatsApp, OpenSSH, and TLS 1.3. If you are looking for independent validation of a cryptographic primitive, "Signal and WhatsApp both rely on it" is a reasonable starting point.

ChaCha20-Poly1305. This is the AEAD (Authenticated Encryption with Associated Data) construction that encrypts and authenticates every packet. ChaCha20 is a stream cipher also designed by Bernstein, and Poly1305 is a message authentication code, also by Bernstein. The combination is specified in RFC 7539. The argument for using this instead of AES-GCM is nuanced and hardware-dependent. On modern x86 CPUs with AES-NI instructions, AES-GCM is fast. On ARM processors without dedicated AES acceleration, which includes a large fraction of routers, embedded devices, and older mobile hardware, ChaCha20-Poly1305 is faster, often dramatically so. Cloudflare documented this in 2015, and it remains broadly true for anything without hardware crypto assist. The more interesting argument is implementation safety. AES-GCM is notoriously difficult to implement correctly without timing side channels; ChaCha20 is designed to be constant-time in software by construction. On servers with AES-NI, the performance difference is modest. On a router running OpenWRT on a MIPS chip, it is the difference between saturating the line and not.

BLAKE2s. This is the hashing primitive, used for key derivation and transcript hashing during the handshake. BLAKE2 is a finalist-derived algorithm from the SHA-3 competition, and it is generally faster than SHA-256 while meeting the same security properties. The "s" variant is tuned for 32-bit platforms, which again reflects WireGuard's goal of running well on embedded hardware.

SipHash24. This one handles internal hash table operations, not cryptographic authentication. The reason it is not just a standard hash function is that hash tables exposed to external input are vulnerable to hash flooding attacks, where an adversary sends packets crafted to collide in the hash table and degrade performance to O(n) per lookup. SipHash24 is a keyed hash that defeats this attack class.

HKDF. The HMAC-based Key Derivation Function, specified in RFC 5869. This is used to derive session keys from the shared Diffie-Hellman outputs, following the Noise framework's key schedule.

That string, Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s, is WireGuard's entire cryptographic identity compressed into 37 characters. Everything the protocol does cryptographically follows from that construction.

The argument against this stack is that if Curve25519 is broken, every WireGuard installation in the world is simultaneously broken, and there is no fallback. Donenfeld's response in the original whitepaper is direct: if a fundamental primitive breaks, updating the protocol is the correct response, not maintaining a legacy negotiation path that keeps the broken primitive available forever. SSL/TLS proved that cipher agility does not actually help you retire broken ciphers; it just means broken ciphers stay available alongside good ones indefinitely, waiting for a downgrade attack. WireGuard will publish a new version when the primitives need changing. In the meantime, the absence of negotiation machinery means there is one fewer attack surface category to worry about.

The Handshake, or 1-RTT With a Surprising Amount of Elegance

WireGuard's key exchange is based on the Noise_IK handshake pattern from Trevor Perrin's Noise Protocol Framework. The "IK" stands for the initiator's static key being known to the responder at the start of the handshake. This is the same assumption as SSH: you know the server's public key before you connect, and you exchange yours during the handshake.

The handshake completes in one round trip. The initiator sends a message containing an ephemeral public key, an encrypted version of its static public key, and an encrypted TAI64N timestamp. The responder replies with its own ephemeral key and a confirmation. Both sides then derive symmetric session keys from the four Diffie-Hellman computations across all combinations of static and ephemeral keys.

Those four DH computations, specifically DH(initiator_ephemeral, responder_static), DH(initiator_static, responder_static), DH(initiator_ephemeral, responder_ephemeral), and DH(responder_ephemeral, initiator_static), are combined through HKDF into a chaining key that feeds the session key derivation. The property this buys you is that compromising any single private key does not compromise the session. An attacker who obtains the responder's long-term static private key after the fact can learn that the initiator connected, but cannot decrypt the session data, because the session keys were also derived from ephemeral values that are generated fresh for each handshake and zeroed afterward. This is perfect forward secrecy.

The handshake also provides identity hiding. The initiator's static public key is encrypted using the responder's static public key before being sent. A passive observer who does not know the responder's private key cannot determine who the initiator is. This is meaningfully stronger than what IKEv2 provides in aggressive mode, where identities are sent in the clear.

Here is where it gets interesting from a DoS perspective. The responder does not allocate any state when it receives a handshake initiation. It validates the first MAC (mac1, derived from the responder's static public key), does the DH computation to decrypt the initiator's identity, and validates the timestamp. If any of those checks fail, the packet is dropped silently. No state was allocated. No response was sent.

WireGuard's stance toward unauthenticated packets is complete silence. If you send a packet to a WireGuard port from an IP that is not a configured peer, you will not receive a connection refused, a port unreachable, or any response whatsoever. From the perspective of an adversary scanning the network, the port does not exist. This is a meaningful operational security property, and it is one that IPSec with IKEv2 does not provide, because IKEv2 responds to initiations from unknown peers during the SA negotiation phase.

The cookie mechanism handles the case where a responder is under CPU load from DH exhaustion attacks. When the responder is overwhelmed, it stops processing handshakes and instead sends cookie reply packets. Subsequent handshake initiations must include a second MAC (mac2) derived from a cookie based on the initiator's source IP address. This provides IP address rate limiting without requiring the responder to perform any expensive DH operations for traffic it hasn't verified.

The Replay Attack Question, or Why IKE Is Haunted and WireGuard Isn't

IKEv2 has a replay attack problem that has required multiple workarounds over its lifetime. The fundamental issue is that IKE exchanges have state, and an attacker who captures and replays an IKE initiation can force the responder to re-create SAs, potentially disrupting active sessions.

WireGuard solves this cleanly with the TAI64N timestamp embedded in the first handshake message. The responder keeps track of the most recent timestamp received per peer and rejects any handshake initiation with a timestamp less than or equal to the stored value. A replayed packet, which has a timestamp from the past, fails this check and is dropped. The responder does not need to track sequence numbers or maintain large windows of recently-seen nonces for handshake packets.

The counterargument is that this ties the replay protection to system clock integrity. If an adversary can manipulate the initiator's system clock into the future, they can potentially pre-stage a handshake initiation that cannot be replayed with a real handshake later. WireGuard acknowledges this and notes it in the known limitations section. It is a real limitation, and it matters in environments where an attacker might control time synchronization. In practice, those environments are also environments where you have much larger problems than your VPN protocol's replay protection.

For data packets after the handshake, WireGuard uses a 64-bit counter that cannot be wound backwards, combined with a sliding window of approximately 2,000 counter values to handle out-of-order UDP delivery. This is standard practice for replay protection in AEAD constructions. The counter is per-session, which means you cannot replay data from a previous session into a new one because the session keys are different.

IKE's replay attack history is a consequence of building a negotiation-heavy stateful protocol. WireGuard's clean approach is a consequence of building a minimal protocol that does one thing and does it well.

Cryptokey Routing, or the Insight That Makes Everything Else Click

WireGuard's routing model is where the simplicity becomes almost embarrassing. Every peer has a public key. Every public key is associated with a list of allowed source and destination IP addresses. When the WireGuard interface sends a packet, it looks up the destination IP in the peer table, finds the matching public key, encrypts the packet to that key, and sends it to that peer's most recently known endpoint. When a packet arrives, it decrypts it, verifies the authentication tag, checks that the inner source IP is in the allowed IPs list for the peer whose key decrypted it, and either passes it up the stack or drops it.

That is the entire routing model. The cryptokey routing table is simultaneously the routing table and the access control list. There is no separate firewall configuration needed to validate that a packet claiming to come from a peer actually came from that peer. Cryptographic authentication is the access control. If you can decrypt a packet with peer A's key and the inner source IP is in peer A's allowed range, the packet is authentic. That is a stronger guarantee than anything you get from IPSec's XFRM layer, which requires you to configure separate SPD (Security Policy Database) and SAD (Security Association Database) entries and trust that the kernel is matching them correctly.

The implication for firewall rules is significant. With WireGuard, your firewall only needs to check source interface and source IP. If it came in on the WireGuard interface from an IP that WireGuard accepted, it is cryptographically authenticated. You don't need the nested policy matching that IPSec's transform layer requires. The configuration is a flat text file with interface settings and peer stanzas. A working WireGuard config for a client connecting to a server is about ten lines:

[Interface]
PrivateKey = <your private key>
Address = 10.0.0.2/24

[Peer]
PublicKey = <server's public key>
Endpoint = server.example.com:51820
AllowedIPs = 0.0.0.0/0

That's it. There are no SA lifetimes, no transform sets, no crypto maps, no IKE phase 1 and phase 2 policies, no aggressive mode versus main mode decisions.

Linus Torvalds, on the Linux kernel mailing list in 2018, said of WireGuard: "Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art."

Torvalds does not use the phrase "work of art" about kernel code. He uses words like "braindamaged" and "complete and utter disaster." This was notable.

The Roaming Behavior, or the Thing That Should Not Work This Elegantly

WireGuard's roaming behavior is the feature that most impresses working network engineers when they see it for the first time.

Here is the problem other VPN protocols have with roaming. IKEv2 added MOBIKE specifically to handle mobile IP address changes, because its predecessor could not do it. The protocol needs to renegotiate or at minimum notify the other end when the endpoint IP changes. OpenVPN has no native roaming and drops sessions when the client's IP changes. Most enterprise VPN clients handle this by detecting the disconnect and reconnecting, which means there is a gap.

WireGuard does not have this problem by design. When a WireGuard responder receives an authenticated data packet from an IP address that differs from the current stored endpoint for that peer, it updates the stored endpoint to the new address. That update happens atomically and requires no round trip. The next packet from the responder goes to the new endpoint. From the application's perspective, there is no interruption.

This means a WireGuard client can move from a WiFi network to a cellular network, change both its IP address and its NAT mapping, and the tunnel continues without a renegotiation, without a reconnection, and without a visible gap to the application. The only requirement is that the client sends a data packet after the IP change. WireGuard's keepalive mechanism handles this automatically.

The reason this is possible is that WireGuard authentication is cryptographic, not endpoint-tied. The responder does not care where a packet came from. It cares whether the packet decrypts and authenticates with the correct peer key. An authenticated packet from a new source IP is not a problem; it is the new endpoint for that peer.

WireGuard's known limitations page is admirably honest about the trade-off this creates. A man-in-the-middle attacker who has intercepted the session and can modify source IP addresses could potentially update the endpoint to a machine they control. The attacker still cannot read or modify the encrypted data, because they do not have the session keys, but they might be able to redirect the server's outbound packets to a different destination. For most deployment contexts, this is an acceptable trade-off. For the paranoid cases, WireGuard allows firewall rules to pin the socket to a specific peer IP, which disables automatic roaming but prevents endpoint hijacking.

The important thing to understand is that IKEv2 with MOBIKE does not actually solve this problem better. MOBIKE's UPDATE_SA_ADDRESSES exchange is an authenticated round trip that updates the endpoint. An attacker who can man-in-the-middle the session can also intercept and replay MOBIKE exchanges. WireGuard's approach is simpler and the security properties are roughly equivalent.

What WireGuard Cannot Do, or The Honest Section

Here is the thing. WireGuard is exceptional at what it does and genuinely unsuited for what it does not do. The mistake is treating it as a universal IPSec replacement. It is not.

PKI and certificate-based authentication. WireGuard uses static public key pairs, distributed out of band. There is no concept of a certificate authority, no X.509 certificate chains, no CRL (Certificate Revocation List) checks, no OCSP, no SCEP. If you are in an environment where certificates are issued by an enterprise CA and devices are authenticated based on their certificate chain, WireGuard requires you to build a separate key distribution layer on top of it. This is not insurmountable, but it is real work, and it is work that IPSec's PKI mode handles natively. Tools like Tailscale and Netmaker exist specifically to solve this key management problem on top of WireGuard's raw protocol.

Multi-site hub-and-spoke topologies with dynamic routing. You can absolutely build hub-and-spoke networks with WireGuard. The configuration is manual, though, and WireGuard has no built-in concept of routing protocols. If you have 50 branch offices and want OSPF or BGP carrying routes between them over WireGuard tunnels, WireGuard will not object, but you need to run those routing daemons yourself, manage the full mesh of tunnels yourself, and handle failover yourself. IPSec with IKEv2 and ISAKMP policies at least has a negotiation framework that some routing platforms integrate with natively. WireGuard does not.

Cipher negotiation for compliance reasons. Some regulated industries require specific cipher suites, typically AES-256 and SHA-256 or stronger, sometimes FIPS-validated implementations. WireGuard uses ChaCha20-Poly1305 and BLAKE2s, which are excellent choices from a cryptographic standpoint but are not FIPS 140-2 validated in most implementations. If your compliance framework requires FIPS-validated cryptography, WireGuard cannot satisfy that requirement. This is a genuinely real constraint, not a bureaucratic obstacle, in environments subject to FedRAMP, FISMA, or certain healthcare regulations.

TCP encapsulation. WireGuard is explicitly and deliberately UDP-only. This is the right call from a performance standpoint. Tunneling TCP over TCP produces catastrophic interactions when the inner TCP stream and the outer TCP connection both respond to congestion events simultaneously, colloquially called TCP-over-TCP meltdown. WireGuard avoids this cleanly by living entirely in UDP. The problem is that many enterprise networks, hotel networks, captive portals, and restrictive corporate firewalls block UDP entirely or throttle anything on non-standard ports. If you need to reliably traverse these environments, you need obfuscation or TCP wrapping at a layer above WireGuard. Tools exist for this, but they are not WireGuard itself.

Identity hiding after handshake compromise. WireGuard provides forward secrecy for data packets. The handshake itself encrypts the initiator's static public key using the responder's static public key. If an attacker later compromises the responder's static private key and has a recording of past handshakes, they can determine who connected (because they can now decrypt the encrypted identity field), but they cannot decrypt the session data (because the session keys used ephemeral values). This is weaker than what Signal's double ratchet provides, but it is meaningfully stronger than what most VPN protocols provide. It is a limitation worth understanding rather than pretending away.

Post-quantum security by default. WireGuard's Curve25519 key exchange is not quantum-resistant. A cryptographically-relevant quantum computer could, in principle, recover the session keys from recorded traffic. WireGuard includes a pre-shared key (PSK) slot specifically to address this, allowing an additional symmetric secret to be mixed into the key derivation. A properly-chosen PSK of sufficient length would maintain security even if the Curve25519 exchange were broken. The mechanism is optional. The PSK needs to be distributed separately, which brings you back to the key management problem.

The Ecosystem That Built on Top

WireGuard's limitations around key management and policy are not surprising to anyone who read the original paper. Donenfeld explicitly scoped the protocol as a tunnel primitive and explicitly left key distribution and connection management as out-of-scope problems for higher layers. This was a deliberate and defensible choice. It was also an invitation.

Tailscale built an entire managed overlay network product on top of WireGuard. Their control plane handles key distribution, peer discovery, NAT traversal using their relay (DERP) servers, ACL management, and device authentication via SSO providers. The data plane is WireGuard. Tailscale effectively added everything that WireGuard intentionally excluded, wrapped in a user experience that is genuinely easier to operate than any IPSec solution that has ever existed. The fact that Tailscale became a viable enterprise product is a vindication of Donenfeld's approach.

NetBird, Netmaker, Headscale, and Firezone are all doing variations of the same thing, adding control planes on top of WireGuard's tunnel primitive. The pattern is consistent: WireGuard handles the cryptography correctly, and everyone builds the management layer they need on top.

This is the opposite of how IPSec evolved. IPSec tried to build the management layer into the protocol, which is why IKEv2 exists and why it is complicated. WireGuard said "not my problem" and let the ecosystem solve it. The ecosystem solved it, in multiple ways, for multiple use cases, without any of those solutions having to carry the weight of the others.

The Cases Where IPSec's Complexity Buys Something Real

To be fair, and this is not easy to say after several thousand words of implicit WireGuard advocacy, there are real deployment contexts where IPSec's complexity is not pointless overhead.

Any network device that shipped before 2020 has native IPSec support and no WireGuard support. That is a large installed base, and it includes most enterprise routers, most carrier-grade equipment, and most managed firewalls from the major vendors. When you need to connect a Cisco ASA to a Juniper SRX, you reach for IKEv2. WireGuard is not on either of those devices.

Policy-based routing at scale, where different traffic flows take different paths based on security policy, is handled more gracefully by IPSec's XFRM layer and SPD than by WireGuard's flatter model. If you need to encrypt certain flows and pass others in the clear based on source/destination tuple matching, IPSec's transform framework has purpose-built infrastructure for this. WireGuard routes based on destination IP and encrypts everything that traverses the interface, which is both simpler and less flexible.

FIPS compliance is real in government and healthcare contexts. WireGuard's ChaCha20-Poly1305 is not FIPS 140-2 validated in most implementations. There are FIPS-validated AES-GCM implementations for IPSec. If your auditor requires FIPS 140-2 validated cryptography and you cannot get a waiver, WireGuard will not satisfy that requirement.

Interoperability with carrier-provided MPLS VPN services and with SD-WAN controllers that speak IKEv2 natively is real. Enterprise branch connectivity products, the kind that plug into a carrier's managed service and automate site-to-site tunnels to the MPLS backbone, speak IPSec. They do not speak WireGuard. Building WireGuard-based replacements for this infrastructure is possible but requires replacing a large amount of ancillary tooling.

None of these arguments make IPSec a better protocol. They make it a better fit for specific legacy and compliance contexts where the installed base and regulatory environment have already decided the answer.

The Uncomfortable Truth About WireGuard's Limitations and Why They're Still Worth It

WireGuard is not post-quantum. It does not have native key management. It cannot traverse environments that block UDP. It won't run on your ten-year-old firewall. It doesn't speak to your CA. It has no FIPS validation. It exposes your traffic patterns to an observer who can see the encrypted UDP flows.

And it is still the right choice for the majority of new deployments.

Here is why. The alternative, IPSec, has 400,000 lines of code that need to be correct. WireGuard has 4,000 lines that have been formally verified by academic cryptographers at Royal Holloway, University of London, and read in an afternoon by security engineers who want to understand exactly what they're running. The attack surface is not just about cryptographic strength; it is about the total amount of code that has to be right. A buffer overflow in the IPSec XFRM state machine, a parsing bug in the IKEv2 certificate handling code, a timing side channel in the AES-GCM implementation, these are real vulnerability classes in large codebases. WireGuard's codebase is small enough that this class of bug is dramatically less likely.

The key management limitation is real but solved. Tailscale, Netmaker, and NetBird provide management planes that run on top of WireGuard's protocol. You are not choosing between "WireGuard with manual key management" and "IPSec with automated key management." You are choosing between "WireGuard-based product with automated key management" and "IPSec-based product with automated key management." At that level of comparison, WireGuard-based products are consistently simpler to operate.

The FIPS limitation is real but narrow. If you genuinely require FIPS 140-2 validated cryptography, that constraint was already going to drive your toolchain choices before you got to the VPN question. It is a constraint that affects a specific set of regulated deployments, not general practice.

The UDP-only constraint is real and occasionally painful. Environments that block UDP are a genuine operational problem. For those environments, tools like udp2raw can wrap WireGuard's UDP traffic in TCP or ICMP. It is an additional layer, but it is a separable additional layer, not something that requires re-engineering the VPN protocol.

The Size of the Code Is the Point

Let's come back to where we started. Less than 4,000 lines of code, excluding the cryptographic primitives.

That number has a specific meaning that is easy to gloss over. Security software's primary attack surface is its own code. Every line of code is a potential bug. Every line of code is something a security auditor has to read and understand. Every line of code is complexity that can interact unexpectedly with adjacent complexity. The relationship between codebase size and audit quality is not linear; it degrades sharply once a codebase exceeds what a small team can hold in their heads.

WireGuard's codebase is small enough that Donenfeld claimed in the original paper that it can be reviewed and audited by a single individual. That claim has been tested. The formal cryptographic analysis by Benjamin Dowling and Kenneth Paterson at Royal Holloway in 2018 verified the protocol's handshake properties under standard cryptographic assumptions. The Linux kernel's security review process examined the code before merging it in 5.6. Individual security researchers have audited it.

Compare that to OpenVPN, whose security depends on OpenSSL, an independent codebase of roughly 500,000 lines with its own security history. Heartbleed was an OpenSSL bug. If your VPN depends on OpenSSL, your VPN security depends on OpenSSL being correct, and OpenSSL being correct is not a constraint you have much visibility into.

WireGuard's cryptographic primitives are also small and well-studied. Curve25519, ChaCha20, and Poly1305 are all Bernstein designs with significant academic scrutiny. BLAKE2 came from the SHA-3 competition. None of them have the implementation hazards of AES without hardware assistance, and all of them are designed with software constant-time implementations in mind.

The audit story is not the most exciting feature. It is not what impresses people in demos. But it is arguably the most important property a security protocol can have in 2026, after two decades of watching large, complex security codebases fail in creative ways.

Where WireGuard Lives Now

WireGuard merged into the mainline Linux kernel in version 5.6, released on March 29, 2020. Since then it has shipped in every major Linux distribution, been ported to Windows (with a native kernel-mode driver), macOS, iOS, Android, OpenBSD, FreeBSD, and NetBSD. AVM's Fritz!Box routers support it natively in Fritz!OS 7.39. It runs on embedded devices with 32MHz processors and on bare-metal servers pushing 800 Gbps.

The ecosystem has grown in directions Donenfeld explicitly expected when he wrote the protocol. Tailscale, which uses WireGuard as its data plane, has become the de-facto standard for easy-to-deploy mesh networking. Mullvad, NordVPN, ExpressVPN, and most major commercial VPN providers now offer WireGuard as an option alongside OpenVPN and IPSec. The Linux kernel's implementation is actively maintained and has received ongoing performance optimizations including AVX SIMD acceleration for the ChaCha20 operations.

The protocol itself has not changed significantly since its NDSS 2017 debut. This is either a sign that it got the fundamentals right, or a limitation of its deliberately narrow scope, depending on your perspective. Both of those things are true.

Oregon Senator Ron Wyden formally recommended in 2022 that NIST evaluate WireGuard as a replacement for existing VPN technologies in government contexts. That recommendation has not yet produced a FIPS-validated implementation, but it reflects how far WireGuard's credibility has traveled from "experimental kernel module written by one person" to "technology a US Senator thinks the federal government should be using."

WireGuard is not going to replace IPSec in every context. Multi-vendor interoperability, legacy hardware compatibility, FIPS requirements, and policy-based routing needs are real constraints in real deployments. IPSec is still the right answer for carrier interconnects, regulated government systems, and environments where the installed base has already made the decision.

For everything else: WireGuard is the right answer. It is secure by default in a way that IPSec has never been. It is auditable in a way that OpenVPN has never been. It roams without drama. It configures without ceremony. It disappears to port scanners.

It did all of that in fewer lines of code than OpenVPN uses to set up a TLS connection.

WireGuard is embarrassing, it is essential, and it is not going anywhere.

Welcome to the right way to build a VPN.