VPN protocols at home: where WireGuard, OpenVPN and IKEv2 differ

Choose the protocol last. WireGuard, OpenVPN and IPsec with IKEv2 are the three options still worth running at home, and the useful difference between them is not a speed ranking but a failure mode: each one breaks somewhere the other two do not. Leviathan Security's TunnelVision disclosure of 6 May 2024 (CVE-2024-3661) makes the case better than a benchmark. The researchers pushed traffic out of the tunnel using a DHCP feature and reported that "the strength of the encryption algorithm a VPN uses makes no difference. TunnelVision's effect is independent of the underlying VPN protocol (e.g., WireGuard, OpenVPN, or IPsec) because it reconfigures the operating system network stack the VPN relies on." They were explicit that "we have not broken the VPN's cryptographically secured protocol, and the VPN is still fully functional." Decide what the tunnel is for. The protocol falls out of that answer.

WireGuard: no negotiation, and a fixed address per key

The WireGuard whitepaper states the design position in one line: "WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility." The consequence is spelled out in the same paragraph: "If holes are found in the underlying primitives, all endpoints will be required to update." There is no cipher list to get wrong and no downgrade to negotiate, and there is also no way to swap a primitive without shipping new software everywhere.

The primitives are named on the project's protocol page: ChaCha20 for symmetric encryption authenticated with Poly1305 using RFC 7539's AEAD construction, Curve25519 for ECDH, BLAKE2s for hashing, HKDF for key derivation, and SipHash24 for hashtable keys. The handshake is a variant of Noise, identified by the literal construction string "Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s", and completes in one round trip: initiator to responder, responder to initiator.

Because the first message must authenticate the initiator, the responder can keep nothing before authentication. The paper's section on that is titled "Silence is a Virtue": "With no state stored for unauthenticated packets, and with no response generated, WireGuard is invisible to illegitimate peers and network scanners." A port scan of the listening UDP port returns nothing at all.

Routing is the part people get wrong. Peers "are identified strictly by their public key, a 32-byte Curve25519 point", and each key carries a list of allowed source IPs. Outbound, the destination address selects the key. Inbound, after decrypting and authenticating a packet, the interface "will only accept it if its source IP resolves in the table to the public key used in the secure session for decrypting it". Roaming follows from the same rule: "Both client and server send encrypted data to the most recent IP endpoint for which they authentically decrypted data."

The timers are fixed and short, which is why a WireGuard interface has no visible connect step.

WireGuard was merged into Linux 5.6, released on 29 March 2020, so on any current distribution it is already in the kernel.

The privacy cost of one key mapping to one tunnel address is real and was demonstrated against a large provider. On 20 May 2026 Mullvad published a fingerprinting write-up: "The issue arises when connecting to different VPN servers with the same internal tunnel address. Then the user is likely to be assigned an exit address with the same relative position in each VPN server's range of exit addresses." A site could therefore link two sessions from two different servers back to one device. Mullvad's interim advice was to "log out and log in again in the Mullvad app if switching servers. This will regenerate the WireGuard key and change the internal IP address." The project's own known limitations page adds a second identity issue: a compromised responder key plus recorded handshakes reveals who initiated, though not what was said.

OpenVPN: the TCP mode is the trap

The default is --proto udp, and the manual is direct about why: "OpenVPN is designed to operate optimally over UDP, but TCP capability is provided for situations where UDP cannot be used." That same page links to an archived copy of Olaf Titz's "Why TCP Over TCP Is A Bad Idea", which explains the failure mode. Titz sets out what happens once the carrier connection starts losing packets: "The lower layer TCP queues up a retransmission and increases its timeouts." Because "the timeout is still less than the lower layer timeout, the upper layer will queue up more retransmissions faster than the lower layer can process them". Titz calls the result "an internal meltdown effect". Those upper layer retransmissions are unnecessary "since the carrier guarantees delivery", but "the upper layer TCP can't know this".

TCP mode is therefore a firewall workaround, not a speed setting, and it costs you exactly when the path is worst. WireGuard refuses to offer it for the same reason, citing "the classically terrible network performance of tunneling TCP-over-TCP".

Data Channel Offload is the answer to OpenVPN's other historic complaint, the trip through userspace for every packet. OpenVPN says netdev maintainers "accepted OpenVPN DCO for inclusion on April 17, 2025", and the kernel module named ovpn "has been merged upstream as of linux-6.16", with the caveat that it "is compatible only with OpenVPN 2.7 and greater". The design limits are worth reading before you assume your config survives: "Layer 3 (dev tun) only", "only the following AEAD ciphers are currently supported: Chacha20-Poly1305 and AES-GCM-128/192/256", and "no support for compression or compression framing". A fast OpenVPN is an OpenVPN configured to look like WireGuard.

IPsec with IKEv2: built for the address moving underneath it

IKEv2 is RFC 7296, October 2014, and carries STD 79. Setup is short: "In the common case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to establish the IKE SA and the first Child SA." Raw ESP does not survive NAT, so home use depends on RFC 3948 (January 2005), "UDP Encapsulation of IPsec ESP Packets", which puts ESP inside UDP on port 4500.

The reason phones prefer it is MOBIKE, RFC 4555, June 2006. "MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change", and the stated use case is exactly the mobile one: "A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another." The move is announced, not inferred: the initiator sends "an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification". Nothing is renegotiated, so the security associations and the authentication survive the handover.

Both mobile platforms ship this. Apple lists under IKEv2 the features "MOBIKE, IKE fragmentation, server redirect, split tunnel" for iOS, iPadOS, macOS, tvOS, visionOS and watchOS. On the other side, "In Android 11, the IPsec/IKEv2 Library module's IKEv2 negotiation library is the platform's default implementation of an IKEv2 client, supporting initial establishment, periodic re-key, dead peer detection, and handoff."

MTU is where most reports of a slow VPN come from

Every tunnel shrinks the usable packet. RFC 2516 (February 1999) already caps a PPPoE link: "the PPP MTU MUST NOT be greater than 1492." Put a tunnel inside that and the budget shrinks again. The wg-quick manual says the interface MTU "is automatically determined from the endpoint addresses or the system default route, which is usually a sane choice", and the script itself subtracts 80 bytes from the discovered path MTU, falling back to 1500 when it finds nothing, which is where the familiar 1420 comes from. OpenVPN defaults --tun-mtu to 1500 and --mssfix to 1492 mtu.

The mechanism that is meant to sort this out is Path MTU Discovery, RFC 1191, November 1990. A host "initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all datagrams on that path with the DF bit set", then learns better from ICMP messages carrying "fragmentation needed and DF set". Those messages routinely never arrive. RFC 8899 (September 2020) is blunt about it: "ICMP messages can be filtered by middleboxes, including firewalls", and "Classical PMTUD is subject to protocol failures. One failure arises when traffic using a packet size larger than the actual PMTU is black-holed (all datagrams larger than the actual PMTU are discarded)."

That produces a specific and very recognisable symptom, described in OpenVPN's own manual: "The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage." Small packets pass, the handshake completes, the status shows connected, and then a large download or an SSH session with a big paste hangs. People report that as a slow VPN and go looking for a faster protocol. It is a size problem.

The manual gives the first thing to try, lowering the maximum UDP packet size to 1300, "a good first try for solving MTU-related connection problems", using --tun-mtu 1500 --fragment 1300 --mssfix. Each of those options "only makes sense when you are using the UDP protocol". On WireGuard the equivalent is setting MTU explicitly in the interface section, well below the automatic value, and testing upward.

A tunnel home is not an exit node

These are two different products that happen to share software.

A self-hosted tunnel back to your own router gives you your LAN: the printer, the NAS, the camera, the admin page. Your public address stays your home address, your home ISP still sees every site you reach, and your ceiling is your home upload speed, not your download speed. If the far end sits behind NAT and sends nothing for a while, the mapping expires; the wg manual suggests that such an interface "might benefit from having a persistent keepalive interval of 25 seconds".

A commercial exit node does the opposite. It removes your ISP as an observer and installs the provider in that seat, which is a transfer of trust, not a removal of it. Australia's competition regulator documented what that can mean on 26 July 2023, when the Federal Court ordered Facebook Israel and Onavo Inc "to each pay $10 million" over the Onavo Protect app. Onavo Protect was "a free app providing a virtual private network (VPN) service", "installed more than 270,000 times by Australian users between February 2016 and October 2017", promoted with lines such as "Use a free, fast and secure VPN to protect personal information", while the companies "shared the personal activity data from users collected by the app in anonymised and aggregated form with parent company Meta". Read the operator's written policy, and prefer one whose business model is the subscription.

Check these before you change protocol

Test the failure you actually have. If a connection establishes and then stalls on bulk transfer, drop the tunnel MTU and retest before touching anything else. If a phone drops the tunnel every time it leaves Wi-Fi, MOBIKE or WireGuard roaming is the fix, not a faster cipher. If you are on an untrusted network, the TunnelVision result applies whatever you run, with one documented exception: "because Android does not implement support for DHCP option 121, it was uniquely unaffected."