VPN Protocols Explained: WireGuard, OpenVPN and IKEv2 Without the Marketing
A VPN protocol is the set of rules that builds and maintains the tunnel: how the two ends agree on keys, how each packet is wrapped, and what happens when the connection moves or breaks. Providers tend to present protocol choice as a speed dial, which is why the comparison pages are full of claims that do not survive contact with the underlying design. The useful questions are about key exchange, the size of the code that has to be correct, and handover behaviour on a phone. Those are the three things this guide explains.
Table of contents
- What a protocol actually decides
- WireGuard: small, opinionated, and state-light
- OpenVPN: the configurable workhorse
- IKEv2/IPsec: mobility as a first-class feature
- What the speed claims leave out
- A practical way to choose
- FAQ
- Bottom line
What a protocol actually decides
Three layers get bundled together in marketing copy and are worth separating. The tunnel carries your packets between your device and the provider's server. The key exchange establishes the secrets used to protect them. The transport decides how the wrapped packets travel across the ordinary internet, usually UDP but sometimes TCP.
The protocol determines all three. It also determines how much code has to be right: a smaller implementation is easier to audit, while a larger one offers more configuration surface. That trade-off, rather than raw throughput, is the main difference between the families below.
- Confidentiality and integrity come from the cipher suite and the way keys are derived, not from the brand of the client.
- Reconnection behaviour comes from how session state is handled, which matters most on mobile devices moving between networks.
- Detectability comes from packet shape and port choice, which is why some networks block one protocol and allow another.
WireGuard: small, opinionated, and state-light
WireGuard is a modern design built around a deliberately small codebase and a fixed set of cryptographic choices. Instead of negotiating among many possible ciphers, it specifies one suite. That removes a whole class of downgrade and misconfiguration problems, and it makes the implementation small enough to review.
Its most distinctive behaviour is how quietly it handles roaming. A peer's identity is a public key, and the endpoint address can change without rebuilding the session: when your phone moves from Wi-Fi to mobile data, packets from the new address are accepted and the tunnel continues. There is no renegotiation pause of the kind older designs need.
The design does make assumptions that providers have to work around. WireGuard peers are identified by static keys, so a provider that wants ephemeral per-session identity, or that assigns addresses dynamically, has to add machinery around the core protocol. This is normal, but it means the provider's implementation still matters. Ask whether keys are rotated and how long a peer identity is retained, rather than assuming the protocol alone answers the privacy question.
OpenVPN: the configurable workhorse
OpenVPN is a mature, widely audited design that runs in user space and can operate over UDP or TCP. Its strength is flexibility: cipher choices, authentication methods, ports, and tunnelling options are all configurable. That is why it remains common in restrictive network environments and in enterprise setups with specific requirements.
Flexibility has a cost. A configuration can be strong or weak, and the difference is not visible from the protocol name. Running over TCP makes the tunnel look more like ordinary web traffic and can help on networks that throttle UDP, but it also introduces the classic problem of TCP running inside TCP, where retransmission timers interfere and throughput can collapse under loss. UDP is the better default on an ordinary connection.
For a reader evaluating a provider, the practical point is that “we support OpenVPN” says very little. The useful questions are which cipher suite is configured, whether the control channel uses a current TLS version, and whether the client exposes a setting that silently weakens the defaults.
IKEv2/IPsec: mobility as a first-class feature
IKEv2 is a key-exchange protocol normally paired with IPsec for the data plane, and it is built into several operating systems rather than shipped as a separate application. Its best-known feature is MOBIKE, an extension that lets a tunnel survive a change of network address. In practice this makes it a common choice on phones that move between Wi-Fi and cellular.
Because the support is native, there is often less third-party code on the device, and the tunnel can be re-established quickly after a sleep or a handover. The flip side is that configuration is less visible to the user: what the operating system negotiates, and which proposals it accepts, may be harder to inspect than a client application's settings.
IKEv2 also uses a distinctive set of UDP ports, which means it is comparatively easy for a network administrator to block or throttle. On a restrictive network, a provider's fallback option matters more than the theoretical advantages of the protocol.
What the speed claims leave out
Comparison pages often rank protocols by throughput in a single test. That number is real for the machine and network on which it was measured, and close to useless elsewhere. Encryption overhead on modern hardware is rarely the bottleneck; server load, distance to the server, and the quality of the underlying connection usually dominate.
Two other factors are systematically omitted. First, handshake cost: a protocol that reconnects quickly after a network change will feel faster on a phone even if its steady-state throughput is lower. Second, packet loss behaviour: a tunnel that handles loss badly can be slower than a nominally heavier one on a congested network.
A more useful way to read a provider's protocol menu is to ask what each option is for: one as the default, one as a fallback on restrictive networks, and one for devices that change networks often. A provider that explains that trade-off is more informative than one that publishes a single winner.
A practical way to choose
- Default to the provider's recommended modern option, usually WireGuard-based, unless you have a specific constraint. Switching protocols is not a privacy setting by itself.
- On a phone that moves between networks, prefer the option with documented roaming or MOBIKE support, and check whether the client reconnects automatically after sleep.
- On a network that blocks UDP or known VPN ports, use the documented fallback rather than guessing; this is where TCP-based configurations earn their place.
- Read the logging policy alongside the protocol page. Protocol choice says nothing about what the provider retains about your sessions.
- Do not treat a protocol as an anonymity tool. It protects the path between two points; it does not change what the destination site learns about your account or your browser.
FAQ
Is WireGuard always the fastest option?
Usually it has the lowest overhead on a given device, but that is not the same as being fastest on your connection. Server capacity, distance, and loss matter more in most cases, and the difference between two well-implemented protocols is often smaller than the variation between two servers of the same provider.
Does the protocol affect whether my provider can log me?
Only indirectly. The protocol determines what the tunnel carries, not what the provider chooses to write down about connection times, assigned addresses, or account usage. Session logging is a policy question, and the answer is in the privacy policy rather than in a protocol comparison table.
Should I switch to TCP if my connection feels slow?
Only when UDP is being blocked or degraded. TCP-inside-TCP tends to perform worse under packet loss, so using it as a general speed fix usually makes things worse. Treat it as a compatibility fallback with a known cost.
Do I need to configure any of this manually?
Most readers do not. Prefer a client that states its defaults clearly and offers a documented fallback. Manual configuration is worth the effort only where you control both ends, such as a tunnel to your own router, or where an organisation requires specific parameters.
Bottom line
Protocol choice is a reliability and compatibility decision far more than a privacy one. WireGuard's small, fixed design removes a lot of configuration risk and handles network changes gracefully; OpenVPN offers flexibility and fallback options at the price of a larger surface that can be configured badly; IKEv2/IPsec is strong where native mobile support and handover matter. None of them changes what your provider logs or what a destination site can see once you are logged in. Read the protocol page for how the client behaves when the network changes, then read the logging policy for the part that actually affects your privacy. A provider that documents both is telling you more than one that simply claims to be the fastest.
If you want to compare current plans in this category, the link below goes to our own product page.