Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Original editorial illustration of four parallel glowing tunnels cut through a rock face: teal and straight, amber and winding with a checkpoint gate, blue bending between two signal towers, violet with a frosted half-closed inspection window, a small traveler standing at the fork where the tunnels split

VPN Protocols Compared: WireGuard vs OpenVPN vs Lightway vs IKEv2

by

VPN Protocols Compared: WireGuard vs OpenVPN vs Lightway vs IKEv2

In brief

  • WireGuard is fastest for most people, OpenVPN TCP gets through strict networks, and IKEv2 holds a phone connection across networks. How to pick by situation.
  • WireGuard’s one real caveat is not speed or security but identity: the protocol has no built-in way to hand out tunnel addresses dynamically, so a naive setup ties a fixed internal address to your key. Reputable providers fix this with double NAT or random per-session addresses — and that fix is the thing to check before you trust a provider’s WireGuard build.
  • OpenVPN remains the fallback that matters: UDP is the fast default, TCP on port 443 is the one that slips through hotel, school, and workplace networks that block everything else.
  • Proprietary protocols are not automatically worse, but they are not automatically equal either. NordLynx is a WireGuard fork with a closed privacy layer; Lightway’s code is open for inspection. The difference is auditability, and it should be stated plainly.
  • The default advice is boring and correct: leave your app on automatic unless you have a specific problem, then change one setting at a time and test.

What a protocol actually decides

A VPN protocol is the set of rules your device and the VPN server use to build the encrypted tunnel, agree on keys, and keep that tunnel alive as conditions change. It does not decide whether your provider logs you, whether a streaming service is fooled, or whether your connection is “secure” in some absolute sense. It decides three practical things: how fast the tunnel runs, how gracefully it survives network changes, and how easily a network in the middle can block or recognize it.

That framing is why protocol comparisons that rank protocols 1-to-5 on “security” are mostly theater. WireGuard, OpenVPN, and IKEv2 are all sound when implemented correctly; the differences that matter to a reader are performance, resilience, and bypass ability. A protocol that is 10 percent faster but drops every time your phone switches from Wi-Fi to cellular is worse for that phone, not better. A protocol that is slower but runs over port 443 is better on a network that blocks everything else, not worse.

There is one more thing a protocol decides that comparison tables usually skip: what your provider must do to run it honestly. WireGuard is the clearest case, and it is where this article starts, because it is also the protocol most apps now default to.

WireGuard: the fast default with one caveat

WireGuard earns its default status honestly. It is a small, modern protocol with a tiny codebase — NordVPN puts its WireGuard-based NordLynx at 10,000 lines of code against OpenVPN’s 400,000 — which makes it easier to audit and faster to run. It uses the ChaCha20 cipher, connects in milliseconds, and sips battery on mobile devices compared with older protocols. If your app offers WireGuard and you have no specific reason to choose otherwise, it is the right starting point.

The caveat is architectural, and it is worth understanding rather than fearing. WireGuard has no concept of a connection and no built-in mechanism for assigning tunnel IP addresses dynamically. Protocols like OpenVPN and IPsec use DHCP-style assignment during connection; WireGuard leaves address allocation to the operator. In a naive setup, each client gets a static internal address tied to its public key, and that key-to-address mapping can persist on the server. A static, identifiable link between a session and a key is exactly what a no-logs provider should not be keeping.

Reputable providers solve this, and the solutions are public. Proton VPN explains that its apps start every WireGuard connection from the same internal address (10.2.0.2) and then use double network address translation to rewrite it to a random, unique session address — so the server never stores a stable link between you and an address. IVPN takes a different route, generating a random tunnel address for each key provided and distributing it to its gateways. NordVPN’s NordLynx uses the same double-NAT idea: the WireGuard core stays, and the address assignment is handled by a layer that does not store your real address.

The practical check for a reader is therefore not “does my provider offer WireGuard” but “does my provider explain how it handles WireGuard addresses.” A provider page that says nothing about this, or that waves the question away, has not answered the one question WireGuard raises. A provider that documents its double-NAT or random-address design, as Proton VPN and IVPN do, has. That documentation is also why the “WireGuard logs you” claim that circulates in forums is wrong in its general form: the protocol requires the provider to do extra work, and the serious providers do it in the open.

One more WireGuard note for the completeness-minded: because it runs only over UDP, it can be blocked on networks that allow only TCP traffic through. That is a network problem, not a protocol flaw, and it is the reason the OpenVPN section below still matters.

OpenVPN UDP vs TCP: the setting that fixes hotel Wi-Fi

OpenVPN is the veteran: open source, audited for years, running on practically every device and router firmware, and available over both UDP and TCP. That dual-transport choice is the single most useful setting in a VPN app, and it is the one people misunderstand most.

OpenVPN over UDP is the fast default. UDP fires packets without waiting for delivery confirmations, so there is less overhead and lower latency. Streaming, gaming, video calls, and general browsing all favor UDP. Start here, and stay here unless something goes wrong.

OpenVPN over TCP is the fallback for hostile networks. TCP numbers every packet, demands receipts, and resends what goes missing — slower, but reliable, and crucially able to run on port 443, the same port HTTPS web traffic uses. A hotel, school, or workplace firewall that blocks VPN traffic will often still allow port 443, because blocking it would break ordinary web browsing. When your VPN will not connect on a restricted network, switching OpenVPN from UDP to TCP is the first fix to try, and it works precisely because the traffic looks like the web traffic the network already permits.

There is a known cost to TCP worth naming: running a TCP tunnel inside a TCP connection can suffer “TCP meltdown” on slow or lossy links, where both layers retransmit and performance collapses. That is why TCP is a fallback, not a default. The rule is simple: UDP until it fails, TCP when it fails, and back to UDP when you are on a network you trust.

For readers coming from our public Wi-Fi guide, this is the mechanism behind that guide’s fix ladder: the captive portal and port-blocking problems it describes are the same problems OpenVPN TCP exists to solve. If you want the full sequence — portal login first, protocol switch second, mobile hotspot test third — start with VPN Not Connecting on Public Wi-Fi: How to Fix It.

IKEv2: the phone protocol

IKEv2, paired with IPsec, is the protocol for a device that moves. Its MOBIKE feature (Mobility and Multi-homing) lets a tunnel survive a switch from Wi-Fi to cellular data without dropping and reconnecting — the exact transition a phone makes dozens of times a day. It is built into Windows, macOS, and iOS, and widely supported on Android, which means it often needs no extra app at all.

That native support is IKEv2’s real advantage, and its limits are the mirror image of OpenVPN’s strengths. IKEv2 uses UDP ports 500 and 4500, which restrictive networks can and do block; it has no TCP mode to fall back on. On an open home network or a phone moving between towers, it is excellent — fast to connect, stable, battery-friendly. On a locked-down hotel network, it is the protocol most likely to fail outright, and the fix is to switch to OpenVPN TCP, not to retry IKEv2 harder.

WireGuard has narrowed IKEv2’s lead on mobile: WireGuard also handles address changes gracefully and uses less battery in most comparisons. IKEv2 still wins one narrow contest — session persistence across rapid network transitions, where MOBIKE remains the more robust mechanism. For most phone users the practical difference is small, and the choice between them should follow what your app defaults to rather than a strong preference either way.

Lightway, NordLynx, and the proprietary question

Two of the biggest providers run their own protocols, and readers reasonably ask whether that is a problem. The honest answer is: it depends on what is open and what is not.

NordLynx is NordVPN’s proprietary protocol built on WireGuard. It keeps WireGuard’s speed and small codebase and adds the double-NAT privacy layer described above. The catch, stated on NordVPN’s own protocol page, is that the double-NAT implementation itself is proprietary: independent researchers cannot fully audit the privacy layer that differentiates NordLynx from standard WireGuard. You are trusting NordVPN’s description of that layer, not an independent review of it.

Lightway is ExpressVPN’s protocol, and its position is different in one important respect: its codebase has been made open source, so anyone can inspect it and assess its security. It is still only available through ExpressVPN’s apps — you cannot take Lightway to another provider — but openness and exclusivity are separate questions, and Lightway answers the openness one better than NordLynx does.

Neither fact makes one provider “better” in general. It means a reader who cares about independent verification should weigh Lightway’s open code against NordLynx’s closed privacy layer, while a reader who cares only about speed in NordVPN’s app can ignore the distinction entirely. What neither protocol should get is a free pass: “built on WireGuard” is reassuring, but the reassurance covers the WireGuard core, not the proprietary layer on top of it. Ask what is open, and treat an unanswered question as information.

The decision table: pick by situation

Situation Try first If that fails
Everyday use at home WireGuard (or automatic) OpenVPN UDP
Phone moving between networks WireGuard or IKEv2 OpenVPN UDP
Streaming or gaming WireGuard OpenVPN UDP
Hotel, school, or workplace Wi-Fi blocking VPNs OpenVPN TCP on port 443 Provider’s obfuscation option
Battery-sensitive mobile use WireGuard IKEv2
Older router or device WireGuard if supported OpenVPN
Maximum auditability OpenVPN or plain WireGuard from a provider that documents its address handling Avoid protocols whose privacy layer is closed

Three cautions apply to the whole table. First, your provider’s implementation matters more than the protocol name: a well-run OpenVPN service beats a sloppy WireGuard one. Second, changing protocols does not change what your provider logs — that is a policy question, answered by audits and court records, not by a settings toggle. Our kill-switch guide makes the same point from the other direction: the setting that protects you when the tunnel drops matters more than the protocol that built the tunnel. If you have not tested yours, see VPN Kill Switch Explained: What It Does and How to Test It. Third, avoid PPTP and L2TP entirely: both are legacy protocols with known weaknesses, superseded by everything above.

What to leave alone

Most readers should change nothing. Modern VPN apps default to WireGuard or an automatic mode that picks sensibly, and automatic mode exists because the right answer depends on the network you are on right now, which changes. Manual protocol selection is a troubleshooting tool, not a daily optimization: pick a setting when you have a symptom — will not connect, keeps dropping, slow on this network — change one thing, test, and keep the change only if the symptom improves.

If you do switch protocols, verify the result the same way you would verify any VPN change: check your visible IP and location, run a DNS and WebRTC leak check, and confirm the kill switch still engages when the connection drops. Our two-minute verification guide walks through all four checks: How to Tell If Your VPN Is Working.

And if you are still deciding whether you need a VPN at all, start with the frame, not the protocol: VPNs Explained: How They Work, What They Protect, and How to Choose One. Protocols are the engine. The threat model is the destination. Pick the destination first.

Sources

Last verified: October 28, 2026.

Related reading: 50+ VPN Statistics for 2026: Usage, Market Size & Risks

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment