WireGuard or IPsec: what we deploy where

Every time somebody opens this argument it turns into a holy war: one side says IPsec is a fossil, the other says WireGuard is a toy. We run our own network and we deploy both. And the honest conclusion, after years of tunnels that have to be brought back up at three in the morning, is a boring one: WireGuard wins on the code and on the day-to-day; IPsec wins on everything around the tunnel. What is interesting is that in 2026 a third factor has entered the conversation that was not there in 2020 — and it comes with a date on it.

The 4,000 lines that won the argument

WireGuard's strong argument was never performance: it was size. Roughly 4,000 lines of code against OpenVPN's 100,000-plus, and an IPsec stack that in practice is two separate things (a negotiation daemon in userspace and the crypto engine inside the kernel) maintained by different people. It landed in the Linux kernel in version 5.6, March 2020, and the line Linus Torvalds wrote on the kernel mailing list in August 2018, asking for it to be merged already, gets quoted so often because it sums up how everyone who has ever debugged a phase 2 feels: "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."

Now the caveat, because that figure gets thrown around too freely: comparing 4,000 lines of a kernel module against a whole IPsec stack is not comparing like with like. IPsec does things WireGuard does not even attempt, and you need some of them. That said, the order of magnitude is real and has a practical consequence that is not cosmetic: surface to audit, and the odds that this week's advisory is about you.

Performance is not the argument (and WireGuard says so)

Credit where it is due, because the project is more honest than most of its fans. On its own performance page, the numbers everybody still quotes — measured on a Linux 4.6.1 box — come with this warning written by the authors themselves: "These benchmarks are old, crusty, and not super well conducted". The same note adds that both WireGuard and IPsec have got faster since, that WireGuard still edges out IPsec in some cases thanks to its multi-threading, that OpenVPN remains extremely slow, and that replacing the figures with newer data is still pending. Meaning: the megabit table you have seen in twenty articles is not even vouched for by the people who published it.

In our experience, on business links the bottleneck is almost never the encryption: it is the link, the cheap box at the far end, a badly calculated MTU or a carrier doing something odd in the middle. If you are choosing a tunnelling protocol by staring at a table of Mbps, you are optimising the wrong variable.

What WireGuard genuinely does better

• There is nothing to negotiate. The cryptographic construction is a single fixed one, baked into the protocol: Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s. No phase 1, no phase 2, no proposals that fail to match, none of the classic "their side shows the tunnel up and ours does not". If both public keys and AllowedIPs are right, it comes up; otherwise it does not.
• Real roaming. The official documentation puts it plainly: each end sends to the most recent endpoint it authentically decrypted from, so there is "full IP roaming on both ends". In practice, a laptop hopping from the office to 4G, or a site on a dynamic IP, stops being a topic of conversation.
• You can read the whole thing. A WireGuard config fits on one screen and can be understood by whoever is on call without having built it. On incident day that is worth more than any feature. It is the same criterion we apply to when SD-WAN pays off and when it is overkill: every layer you add has to be one you can debug at dawn, not just draw on the proposal.
• It behaves behind NAT. A PersistentKeepalive of 25 seconds — the value the manual itself recommends for interfaces that rarely send traffic and sit behind NAT — keeps the router's mapping alive and that is the end of it. No dead peer detection to tune, no timers spread across three different places.

What IPsec still does better (and it is not nostalgia)

• You do not always own the other end of the tunnel. The firewall the customer already has, the other site's provider router, the public cloud: they all speak IKEv2 and not all of them speak WireGuard. AWS's documentation says it flatly — "Site-to-Site VPN supports Internet Protocol security (IPsec) VPN connections", with IKEv2 on the feature list — and the same goes for the rest of the managed VPN services out there. Choosing WireGuard requires both ends to be yours, or to want to be.
• WireGuard does not know what a person is. There is no concept of a user or a session: there are public keys and allowed ranges, full stop. For employee remote access that means corporate identity, MFA, onboarding and — above all — offboarding are yours to build on top, with everything that implies the day somebody leaves. IKEv2 ships EAP and plugs into RADIUS and user certificates without inventing anything.
• UDP only, and sometimes that matters. WireGuard's documentation is explicit: "WireGuard explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP." Technically they are right. Operationally, the hotel Wi-Fi that only lets 443/TCP out does not care — and we have already written about how hostile those networks are. They also note that "WireGuard does not focus on obfuscation": where somebody filters deliberately, it is not the tool.
• What cannot be negotiated cannot be changed either. WireGuard's fixed cryptography rules out weak suites and downgrade attacks, which is precisely IPsec's historical sin. The price is symmetric: the day an algorithm has to change, there is nothing to adjust — you change protocol version.

The 2026 factor: both are late to post-quantum

This is why we are reopening the comparison today: it has stopped being theoretical and now has a calendar. In June 2025 the EU's NIS Cooperation Group published a coordinated roadmap recommending that Member States start their national post-quantum transition strategy by the end of 2026 and have high-risk use cases migrated no later than the end of 2030. On the other side of the Atlantic, the public draft of NIST IR 8547 (November 2024, still not finalised) puts an expiry date on the very key exchange your tunnels use today: ECDH is deprecated after 2030 at its 112-bit parameters and disallowed — in every variant, 128-bit and above included — after 2035.

Neither protocol, as deployed in most places today, is resistant to a quantum computer. WireGuard says so itself, with the honesty that does it credit: "WireGuard is not, by default, post-quantum secure", and offers a pre-shared key mixed into the key exchange as the remedy. The curious part is that IPsec has exactly the same workaround, and with an RFC number on it: RFC 8784, June 2020, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security". The same patch WireGuard had been carrying since its 2017 paper, only standardised.

And here is the twist that we find the genuinely interesting part. Cryptographic agility, IPsec's sin for twenty years, is today its way out. Since RFC 9370 (May 2023), IKEv2 can chain several key exchanges inside the negotiation itself and combine a classical one with a post-quantum one, so the final secret is derived from all of them: it is enough that one holds. WireGuard solved yesterday's problem — that rubbish got negotiated — and that is why it has tomorrow's: there is nothing to negotiate when what you need to do is change. Its path runs through a new protocol version or a post-quantum handshake layered on top; neither of those happens on a Tuesday afternoon.

Without the drama, because fear is easy to sell here: for most companies 2030 is not an emergency, it is a renewal date. Today's real risk has a name — "harvest now, decrypt later" — and it only bites if what travels through that tunnel will still be sensitive in ten years: medical records, trade secrets, long-lived contractual secrets. If yours carries ERP traffic that expires in a quarter, breathe. But the box you buy this year will probably still be there in 2030, and that is a question for today: does the vendor have a post-quantum path, or are they selling you hardware with a cryptographic expiry date?

What we deploy, and where

We are a network operator with our own network and we do not resell anybody's licences, so there is no commission to defend here. These are the house rules, as they stand:

• Between machines and sites where we control both ends: WireGuard. Linux to Linux, virtualisation nodes, internal services talking across datacentres. Fewer moving parts, fewer 3 a.m. calls.
• Against a third party's equipment or a managed cloud: IPsec/IKEv2, no argument. A tunnel you have to document so the provider on the other end can follow it gets built with what that provider knows how to read. Fighting this wastes time and makes you look bad.
• Remote access for people: the tunnel is the least of it. The problem there is not the protocol, it is identity — who gets in, with which factor, and what happens when that person leaves. Choosing WireGuard or IPsec without solving that is decoration.
• What we do NOT do: replace a working IPsec because WireGuard is more modern. A stable tunnel nobody has touched in three years is worth more than forty lines less of config. Migrating it has a real cost — window, testing, documentation, the scare — and the benefit, if the current one gives no trouble, is zero.

And a reminder we always give, because the tunnel takes all the attention and then the obvious happens: encrypting traffic does not defend the link. If somebody saturates your line, it makes no difference what protocol is inside; that gets solved upstream and with whoever runs the network, not at your end.

What we ask before deciding

• Who owns the other end? If it is not you, the answer is already decided and it is not WireGuard.
• Does it connect machines or people? Machines, WireGuard fits. People, you need identity, and there the tunnel is only half the problem.
• From which networks will it come up? If it has to work from hotels, airports and customers with filtered egress, expect UDP not to get through every time.
• How many years does what goes through it have to stay secret? If the answer is more than five, the post-quantum calendar is already yours and it is worth checking what path your equipment has.

The tunnel was never the project

After all that, the conclusion we reach is not very epic: the protocol choice is the least important decision about your VPN. What decides whether that connection gives you trouble is who documents it, who monitors it, who revokes access when somebody leaves and who knows what to do when it stops coming up. WireGuard fixes none of that, and IPsec breaks none of it.

So the question we leave is not which of the two is better. It is this: could you say today how many tunnels your company has up, to whom, who built them and which one stopped making sense two years ago? Hardly anybody keeps that inventory up to date, and when it does get done properly some tunnel usually turns up pointing at a supplier nobody works with any more. That worries us more than the name of the protocol.

Sources (verified): primitives and the fixed Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s construction, plus pre-shared key mode, at wireguard.com/protocol; "full IP roaming on both ends" at wireguard.com; the absence of TCP ("WireGuard explicitly does not support tunneling over TCP…"), the lack of obfuscation and "WireGuard is not, by default, post-quantum secure", in known limitations; the "These benchmarks are old, crusty, and not super well conducted" warning — together with the note that both have got faster since and that WireGuard still edges out IPsec in some cases thanks to multi-threading — at wireguard.com/performance; the 25-second keepalive and the absence of any user or session concept, in the wg(8) manual. The ~4,000-lines figure against OpenVPN's 100,000-plus and the merge into kernel 5.6 (March 2020), from BleepingComputer; the Linus Torvalds quote (kernel mailing list, August 2018, asking for it to be merged), as recorded by The Register. IPsec: RFC 8784 (June 2020, "Mixing Preshared Keys in IKEv2 for Post-quantum Security"; WireGuard's pre-shared key mode predates it, from its 2017 paper) and RFC 9370 (May 2023, multiple key exchanges in IKEv2, allowing classical and post-quantum to be combined). IPsec/IKEv2 support in AWS Site-to-Site VPN, from its official documentation. The European calendar (national strategy started before the end of 2026, high-risk use cases migrated no later than the end of 2030), from the NIS Cooperation Group's coordinated roadmap; ECDH deprecated after 2030 at its 112-bit parameters and disallowed in every variant after 2035, from the public draft (November 2024, not finalised) of NIST IR 8547. Spanish and Catalan quotations translated by us from the English originals. The criteria, the examples and the opinions are ours.