Why the choice of VPN protocol makes a difference
What decides the speed of a VPN connection, its security, how well it survives switching between mobile networks and whether it can get through restrictive firewalls is not the server but the protocol in use. Even with the same VPN provider, choosing between WireGuard and OpenVPN, or between IKEv2 and L2TP/IPsec, makes a direct difference to connection speed, to whether the connection drops when moving between mobile data and Wi-Fi, and to whether corporate network filters block the traffic. To pick the right protocol you need to know the architecture and design goals of each one.
WireGuard: a small codebase and modern cryptography
WireGuard is the newest VPN protocol, merged into the Linux kernel in 2020. Its design goal is simplicity: the codebase consists of only a few thousand lines, compared with OpenVPN's tens of thousands. That both makes auditing easier and makes the protocol fast. WireGuard uses modern cryptographic primitives such as ChaCha20 encryption and Curve25519 key exchange; thanks to a minimal handshake, setting up a connection is almost instant. It is built in from Linux kernel 5.6 onwards and, because it runs at kernel level, it creates less CPU load than userspace protocols. By design it only uses UDP (default port UDP 51820) — an advantage for speed, but easily blocked on restrictive networks that only allow TCP 80/443.
OpenVPN: TLS-based flexibility and getting through firewalls
OpenVPN is a proven protocol that has been in use for more than 20 years. Being built on TLS, it offers flexibility in encryption options. Its standout strength is that it can run over TCP 443 (the standard HTTPS port); that makes OpenVPN traffic indistinguishable from ordinary web traffic. This property is the main reason OpenVPN is still preferred when facing corporate networks or restrictive country-level filters. By default it uses UDP port 1194, but it can also run over TCP. The TLS and OpenSSL layers cause slightly more processing overhead than WireGuard; when the IP address changes the session has to be re-established, so it does not give a seamless handover.
IKEv2/IPsec: seamless roaming on mobile networks
The distinguishing feature of IKEv2/IPsec is the MOBIKE (Mobility and Multihoming) extension. This extension keeps the VPN connection going without dropping when a device switches from Wi-Fi to mobile data. That is why IKEv2, along with its built-in support in the iOS and Android operating systems, is preferred as the default protocol of most mobile VPN applications. In security terms it is a strong protocol built on IPsec encryption standards. It uses UDP port 500 for key exchange and UDP port 4500 for connections behind NAT; because these particular ports are frequently blocked under strict firewall policies, IKEv2's firewall traversal performance is weak.
L2TP/IPsec: old, but the widest compatibility
L2TP provides no encryption on its own; that is why it is always used together with IPsec. This double encapsulation (data inside L2TP, encryption with IPsec) adds overhead and leaves L2TP/IPsec at a low-to-medium level for speed. Its security is adequate but older: many consumer setups rely on pre-shared keys, which is a weaker model than certificate-based IPsec configurations. It is weak on mobile roaming and firewall traversal. On the other hand, it is supported out of the box on almost every operating system — including very old devices. That makes it a compatibility solution for cases where modern protocols are not supported.
The protocols compared
| Protocol | Speed | Security | Mobile Roaming | Firewall Traversal | Compatibility |
|---|---|---|---|---|---|
| WireGuard | Very high (UDP, minimal handshake, kernel level) | Modern (ChaCha20, Curve25519), small codebase | Good (the stateless design handles IP changes smoothly) | Limited (UDP only, can be blocked outside TCP 80/443) | Good but newer (Linux 5.6+, wide client support) |
| OpenVPN | Good (slightly more overhead because of TLS + OpenSSL) | Proven, TLS-based, flexible cipher options | Medium (the session is re-established when the IP changes) | Excellent (looks like HTTPS over TCP 443) | The widest (20+ years, supported almost everywhere) |
| IKEv2/IPsec | Good | Strong, built on IPsec encryption standards | Excellent (the MOBIKE extension) | Weak (UDP 500/4500, often blocked) | Good, built into mobile operating systems |
| L2TP/IPsec | Low-medium (double encapsulation overhead) | Adequate but old (a pre-shared key in most setups) | Weak | Weak | Very wide, even on old devices |
Which protocol to choose in which scenario
A theoretical comparison is not enough on its own; what really decides is the use case. On a site-to-site connection that stays permanently open between two data centres, where speed and low latency come first, WireGuard's small codebase and minimal handshake are an advantage. For remote workers connecting from a corporate office behind a strict firewall that only allows ports 80/443, OpenVPN's ability to run over TCP 443 is the decisive feature that keeps the connection from ever being cut. For users constantly on the move in the field, switching between Wi-Fi and mobile data on a phone, IKEv2/IPsec's MOBIKE extension keeps the connection going without them even noticing it dropped. L2TP/IPsec should only be chosen when compatibility with an old router or operating system that does not support modern protocols is required; it should not be the first choice for security-sensitive data.
Common mistakes
- Using L2TP/IPsec for security-critical traffic: a pre-shared key based configuration is weaker than certificate-based IPsec, and L2TP itself provides no encryption at all.
- Ignoring the fact that WireGuard only uses UDP, and then not understanding why there are connection problems behind a network that only allows TCP 80/443.
- Choosing IKEv2 on a network where UDP ports 500 and 4500 are blocked, and being surprised that the connection never establishes.
- Forgetting to forward UDP port 4500, needed for NAT-T (NAT Traversal), on IKEv2/IPsec connections behind NAT and opening only UDP 500; in that case the key exchange starts but the real data traffic never flows.
- Keeping the default MTU value without accounting for the header overhead the tunnel protocol adds; this leads to connection problems that end in large packets being fragmented or silently dropped.
Choosing a protocol is an engineering decision that changes with your priorities: is speed, mobile continuity, firewall traversal or wide device compatibility the most important? You can use the comparison tool below to tick your priorities and see which protocol suits you.