WireGuard vs OpenVPN: speed, code size and what is left out

What the two are, as each side describes them

Start with how the projects describe themselves. The WireGuard project page says WireGuard wraps IP packets in UDP: you add a WireGuard network interface, give it your private key and your peers’ public keys, and send packets across it. It says the software was first released for the Linux kernel and is now cross-platform, naming Windows, macOS, BSD, iOS and Android, and it describes itself as “under heavy development.” It also says it intends to be considerably more performant than OpenVPN. That is a stated intention and not a measurement; the measurements come from a lab, further down.

Identity in WireGuard is a public key. The project compares swapping them to swapping SSH keys, and says each peer’s list of allowed IP addresses works as a routing table for outgoing packets and as an access list for incoming ones, an arrangement it calls Cryptokey Routing. The primitives are fixed: ChaCha20 with Poly1305, Curve25519, BLAKE2s, SipHash24 and HKDF, with a handshake built on the Noise framework. The protocol page says the handshake runs every few minutes so that keys rotate, which is how it provides perfect forward secrecy.

OpenVPN’s documentation page on its cryptographic layer describes two authentication modes: a pre-shared static key, or TLS with certificates, where each side has to present its own. In TLS mode the page says the TLS session is multiplexed with the encrypted data stream, and that the IP packets themselves are tunneled over UDP without a reliability layer. It also describes the tls-auth option, in which a pre-shared key signs the packets of the TLS handshake, so that, the page says, an attacker cannot even start a handshake without the right signature. Cipher, key size and digest are chosen through OpenSSL’s EVP interface, which the page says lets the user select an arbitrary one of each.

One caution about that page. It says BlowFish is the default cipher and SHA1 the default digest, and it refers to a key method that will become the default in OpenVPN 2.0. That is the wording of an old document. Palo Alto Networks describes common OpenVPN setups with AES-256, so we use the documentation page for the structure of the two authentication modes and not for defaults.

On transport, Palo Alto Networks and RTINGS both describe OpenVPN as running in TCP and UDP modes. RTINGS says WireGuard only operates in UDP mode and does not offer a TCP mode; wireguard.com says the same thing as a limit, which is taken up below. It helps to know who is speaking. wireguard.com is the project’s own site. openvpn.net belongs to OpenVPN Inc., whose comparison page promotes its own Access Server and CloudConnexa products. RTINGS says it is supported by memberships and that it may earn an affiliate commission when you buy through links on its site.

Why WireGuard is called smaller, and who gives a number

The claim that WireGuard is the smaller of the two appears in three of the pages, but only two of them put a number on it. Palo Alto Networks says the complete protocol is implemented in fewer than 4,000 lines of code for the Linux kernel. RTINGS says about 4000 lines, against hundreds of thousands for OpenVPN. wireguard.com gives no figure at all: it says WireGuard is meant to be implemented in very few lines and to be comprehensively reviewable by single individuals, and it calls the codebases of IPsec implementations and of OpenVPN with OpenSSL gigantic, an overwhelming task to audit even for large teams of security experts.

RTINGS draws the same line from the other side. It says OpenVPN is open source and has been through numerous extensive security audits over its decades, and that it is still widely considered one of the best VPN protocols. It also says the code is so large that review by individuals is highly impractical and that the size gives bugs a much wider attack surface. Palo Alto Networks reads the size difference as a smaller attack surface for WireGuard and an easier audit, and it describes OpenVPN as battle tested over a longer period.

The second difference is the choice of ciphers. RTINGS says WireGuard only supports one cryptographic suite, while OpenVPN can also be configured with AES-256. Palo Alto Networks describes both the same way and draws a consequence: OpenVPN’s flexibility introduces risks if it is not correctly implemented, and WireGuard’s fixed suite avoids downgrade attacks. RTINGS adds the point from the customer’s seat: as a subscriber to a VPN service you are at the mercy of how the provider configures its OpenVPN servers, so the experience can vary a great deal from server to server.

Then the handshake. Palo Alto Networks says WireGuard’s handshake completes in 1.5 round trip times. wireguard.com describes a message from the initiator, a reply, and a rule that the responder waits for one encrypted data packet from the initiator before using the new session.

What the lab measured, and what it cannot tell you

RTINGS ran the only head-to-head test of the two protocols that we read in full, and it says what it did. It set up four identical Lenovo ThinkPad P14s Gen 6 laptops running Windows 11, each with Speedtest.net’s command-line tool. The first was a control, testing from its Montreal office network to a Speedtest server in London. The second and third connected to Mullvad’s OpenVPN servers in London with the OpenVPN Community Client, one over TCP and one over UDP; the fourth connected to Mullvad’s WireGuard servers in London with the WireGuard client. RTINGS says it used each protocol’s native client rather than Mullvad’s app, and ran the test every 40 minutes for 12 hours, overnight.

The averages are in the figure below. WireGuard reached 353.6 Mbps down and 366.0 up, OpenVPN over UDP 149.1 and 125.8, OpenVPN over TCP 44.1 and 39.2, and the control 897.0 and 918.5. RTINGS reports 15.2 percent packet loss for OpenVPN over UDP and none for the others. It describes WireGuard as significantly faster, the clear winner on raw speed, and says WireGuard delivers significantly faster downloads than OpenVPN in either mode without suffering from packet loss.

Three details limit how far to carry those numbers. First, the OpenVPN UDP row rests on 9 successful tests where the others have 19: RTINGS says ten of its UDP tests failed and that it cannot say for sure why, giving as possible causes an error in the Speedtest program or the high packet loss. Second, WireGuard had the highest download latency under load, 611.6 ms against 323.4 for OpenVPN over UDP and 360.5 for TCP; RTINGS offers two possible reasons for the higher latency, buffer queuing caused by the higher throughput or routing over a trans-Atlantic path, and says WireGuard also had slightly more loaded jitter. It says you would notice this only while using the full connection and doing something latency-sensitive such as gaming or a video call. Unloaded ping latency ran from 80.6 to 92.7 ms across the four setups, which RTINGS calls no significant difference.

Third, RTINGS itself says the results are highly dependent on the VPN provider, its server infrastructure and load, and on physical network attributes such as where the server sits, and that connecting to servers in Montreal would very likely have produced significantly different results. It also says the results are comparable to each other and show the general trends well. This was one provider, one server location and one laptop for each protocol, so the figure is one measurement and not a ranking.

The vendor’s answer: kernel mode and parity

OpenVPN Inc.’s comparison page answers the speed result directly, and its claims should be read as a vendor’s. It reprints the RTINGS numbers for WireGuard, OpenVPN over UDP and OpenVPN over TCP and notes that OpenVPN ran in userspace mode in that lab test. It then says that with Data Channel Offload (DCO), which moves the packet encryption work into the kernel, OpenVPN reaches parity, with either protocol ahead depending on the test.

The page gives several conditions. It says the ovpn kernel module ships with Linux since version 6.16, that DCO comes with OpenVPN 2.7 and later on Linux and Windows, and that mobile clients still use userspace, where, in its words, WireGuard keeps its edge. Its own comparison table adds that DCO is mainline only since kernel 6.16, so, it says, not yet on most installed systems. For evidence it cites GL.iNet’s tests of its Mudi 7 travel router, where its chart shows OpenVPN with DCO at 700 Mbps and WireGuard at 600, and says the same company’s Flint 3 router lists 680 Mbps for both.

We did not check any of this at the source. The RTINGS test did not use DCO, and the pages we read do not include an independent lab measurement of it, so the two results sit side by side without one overturning the other. A 2024 study, of which we read only the abstract, compared WireGuard with OpenVPN and IPsec on throughput, latency and jitter in a simulated Internet-of-Things environment. Its abstract mentions disadvantages for WireGuard in that environment alongside advantages in setup time, performance and compatibility, and gives no numbers.

What WireGuard leaves to you

The project is open about its scope. Its home page says all issues of key distribution and pushed configurations are out of scope for WireGuard and are better left to other layers, “lest we end up with the bloat of IKE or OpenVPN.” In practice the model is the one it compares to SSH: both parties hold each other’s public keys and then start exchanging packets. RTINGS describes the same arrangement, with each peer configured with the other’s public key, and says VPN clients can automate this step and generate the configuration files for you.

OpenVPN Inc.’s page lists what follows from that choice, again as a vendor describing a rival. It says WireGuard’s identity model is a static key pair, with users out of scope by design, so there are no accounts, multi-factor login or single sign-on in the protocol. It says addressing means hand-editing every peer, with one static IP per device, and that revoking someone means touching every peer. It says WireGuard works at layer 3 only, so it cannot bridge Ethernet, and that a peer has one endpoint, so there is no failover to a second server. For OpenVPN it lists the cost: a configuration that is longer, with a certificate authority and a certificate per client in the setups it describes, though it mentions a peer-fingerprint mode from version 2.6 for small setups.

wireguard.com then lists limits of its own, summarized in the figure below. It says WireGuard does not focus on obfuscation, which should happen at a layer above, and that it explicitly does not support tunneling over TCP because of the classically terrible performance of TCP over TCP; turning WireGuard’s UDP packets into TCP is the job of an upper layer, which it says projects like udptunnel and udp2raw can do. Palo Alto Networks says WireGuard does not inherently include stealth capabilities and that, like all VPNs, it can potentially be detected by traffic analysis. OpenVPN Inc.’s page says both raw protocols are fingerprintable by modern deep packet inspection and that OpenVPN has a mature ecosystem of wrappers built around it.

The same project page lists less obvious items. Roaming happens without an additional round trip or authentication, so an active man in the middle can replace source IP addresses; the page says the packets stay indecipherable to that attacker and that ordinary firewalling can lock the socket to one address. The handshake encrypts the sender’s public key with the responder’s static key, so someone who obtains the responder’s private key and a log of earlier handshakes could work out who sent handshakes, though not what was inside them. WireGuard uses the system time as a monotonic counter, so the clock should not be under a hostile party’s control, and there are a few issues with detecting routing loops.

Where the pages disagree

Stored data. Palo Alto Networks says that in its default setup WireGuard does not store any personally identifiable information or persistent user data. wireguard.com describes the interface remembering, for each peer, the most recent Internet endpoint that authenticated packets came from, and associating each public key with a list of allowed IP addresses. The two pages do not refer to each other. They may be using different meanings of personal data, or describing different layers, and the pages we read do not settle it, so we set the two statements side by side.

Post-quantum. wireguard.com says WireGuard is not, by default, post-quantum secure, that the pre-shared key can add a layer of post-quantum secrecy, and that the best bet is to run a post-quantum handshake on top and insert that key into the pre-shared key slot. OpenVPN Inc.’s page says OpenVPN inherits new key exchanges from its TLS library and that a hybrid post-quantum exchange is on by default with OpenVPN 2.7 and OpenSSL 3.5. That is the vendor’s statement and we did not verify it.

Security of the primitives. RTINGS says ChaCha20, Poly1305 and Curve25519 are among the newest and most secure cryptographic technologies available, with no known security vulnerabilities. wireguard.com says it makes conservative choices and has been reviewed by cryptographers, calls itself under heavy development, and publishes the limitations above. Palo Alto Networks says WireGuard’s tunnel is safe under proper configuration and that no system is impervious, and calls the fixed suite potentially more secure, assuming the absence of unforeseen vulnerabilities. OpenVPN Inc.’s FAQ says both are secure when configured correctly and describes WireGuard’s codebase as smaller and formally verified; that is again a vendor speaking.

Which is better. Palo Alto Networks says neither protocol is necessarily better: WireGuard excels in speed and simplicity, OpenVPN is more established and configurable, and it says they will likely coexist. RTINGS says WireGuard is likely the best protocol if you use a commercial provider and your device supports it, while OpenVPN absolutely has its place for flexibility or TCP fallback. OpenVPN Inc. says WireGuard’s simplicity is hard to beat for a personal tunnel on friendly networks, and that the question changes when the network gets hostile or the user list gets long.

Which one fits which situation, as the pages put it

The pages do not share a verdict, so this section sets out the situations each one names. We did not test any of these situations.

A network that blocks UDP. RTINGS names this as the case for OpenVPN: some networks completely block UDP traffic, WireGuard has no TCP mode, and OpenVPN can use TCP. OpenVPN Inc. adds that OpenVPN falls back to TCP on port 443 and speaks through HTTP and SOCKS proxies, and says WireGuard cannot get through a mandatory proxy at all. wireguard.com says the TCP step belongs to a layer above WireGuard.

One person, one server, friendly networks. The project says it aims to be as easy to configure and deploy as SSH, and OpenVPN Inc.’s page shows a complete WireGuard client configuration that runs to seven lines, while its comparison table says a working WireGuard config is about 10 lines. RTINGS says WireGuard’s simplicity makes it easy to configure securely and its lightweight design gives better speeds, with the proviso that OpenVPN is the one to use if you need its flexibility.

A company with accounts to manage. OpenVPN Inc. says its products give accounts with multi-factor login, SAML and LDAP, so you provision and revoke people and not configuration files. That is a vendor describing its own products. Palo Alto Networks frames the enterprise choice as a balance: OpenVPN for maturity and granular control, WireGuard for performance and modernity, and it says WireGuard may not yet suit every complex scenario OpenVPN handles. Its closing line is that the choice may involve deploying both.

Small devices. The 2024 study abstract frames WireGuard as a candidate for resource-constrained Internet-of-Things devices and says further testing is needed. We read only the abstract and cannot say more than that.

Using both. OpenVPN Inc.’s FAQ says yes, and describes teams running WireGuard for a personal tunnel or homelab and OpenVPN for company access that must work from any network. It says the two coexist on the same router or firewall and that pfSense and OPNsense ship both. Palo Alto Networks, as above, says the choice may involve deploying both.

What the pages we read do not say is also worth stating. They do not report a measurement on phones, and they do not name an independent security audit of WireGuard’s code with a date and a reviewer; wireguard.com points to a formal verification page and an academic whitepaper, and openvpn.net mentions an independent audit with findings fixed in version 2.4.2 without naming who did it.