WireGuard or IKEv2: What Moving Between Networks Decides
The usable difference between these two is not in their cryptography and not in their packet formats. It is a question of where the tunnel lives: IKEv2 with IPsec is implemented inside the networking stack of every major operating system, while WireGuard arrives on your device inside an application. Everything that follows from that — what happens when your phone changes networks, what survives an app being killed, what a device you do not administer will let you configure at all — is decided by that one structural fact.
This post takes the mobility and integration axis; the code-and-configuration contrast between the two modern designs is how OpenVPN and WireGuard differ by design, and the layer model both sit inside is which part of your VPN is the protocol.
What “roaming” actually asks of a tunnel
Your address changes underneath a connection that is supposed to continue.
Walk out of your house and the phone drops off the wireless network and onto mobile data. The address your device presents to the internet changes completely, and so does the path. A tunnel established from the old address now has an outer packet header that no longer matches where you are.
There are only two ways to cope. Tear the tunnel down and build a new one from the new address, which is correct but visible — connections inside the tunnel break, and anything mid-transfer restarts. Or keep the tunnel’s inner state and update the outer address, so that applications never learn anything happened. The second is what mobility support means, and both of these protocols have a version of it.
How each one survives the handoff
IKEv2 has an explicit mechanism for it; WireGuard gets it as a side effect of having no connection.
IKEv2 pairs with an extension whose entire purpose is address changes mid-session. The two ends keep the security association and exchange a short update telling the peer where to send packets from now on. Because it is deliberate signalling, either end can initiate it, and the server is told rather than left to infer.
WireGuard reaches the same outcome by a different route. Its peers are identified by key, not by address, so when an authenticated packet arrives from somewhere new the server simply records the new source and replies there. Nothing needed renegotiating because nothing was tied to the old address in the first place.
The difference in feel comes from who notices first. WireGuard’s update is triggered by your device sending something, so the tunnel effectively repairs itself on your first outbound packet after the move. If your phone has been idle, that first packet may be the one you generate by opening an app, and the tunnel appears to hesitate briefly. IKEv2’s signalling can happen because the operating system told the VPN stack that the interface changed — before you touch anything.
That is not a benchmark claim, and neither approach is broken. It is a difference in what triggers the repair.
Living in the OS versus living in an app
This is the part that decides the choice more often than any property of the tunnel itself.
IKEv2 with IPsec is implemented in the networking stack of the major desktop and mobile platforms. You can configure it in system settings with a server address and credentials, no third-party software involved. The operating system then treats it as its own: it knows about the tunnel when the device sleeps and wakes, when interfaces come and go, and when a managed configuration says the tunnel should always be on. Connect-on-demand rules — bring the tunnel up when this network is joined, or whenever any traffic wants to leave — are platform features rather than app features.
WireGuard is not in those stacks the same way. On mobile, an app providing a WireGuard tunnel does so through the platform’s VPN interface, which is a real integration but a different one: the app is the tunnel provider, and it must be installed, permitted, and running. On desktop it is usually a service the provider installs.
What follows is practical rather than theoretical. A tunnel configured in system settings survives an app being force-quit, failing to launch after an update, or being unavailable on a device where you cannot install software. A tunnel provided by an app can do things no system dialogue exposes — split routing, provider-specific server selection, obfuscation wrappers, its own status reporting — but it depends on that app being alive.
The network’s opinion matters too
Restrictive networks treat these two very differently, and neither has a TCP escape hatch.
IKEv2 and IPsec use well-known UDP ports that have been recognisable for decades, which is exactly why a locked-down network will often drop them outright. WireGuard uses UDP on whatever port the provider chose, which is less immediately recognisable but no less UDP — a network that permits only TCP to a couple of ports blocks both.
This is a common source of the complaint that a VPN “works at home but not here”. The tunnel is fine; the network is discarding it. When that happens, the fix is usually neither of these protocols but a transport that can survive a hostile path, which is the subject of obfuscated servers and, at the more mundane end, an OpenVPN profile running over TCP.
Where the platform makes the decision for you
Sometimes only one of the two is genuinely available to you.
A corporate or school device with a managed VPN configuration is typically an IPsec arrangement, and installing a different client is not on offer. A device where you have no rights to install anything is in the same position. Conversely, a provider’s advanced features are usually in the app, so if you want per-application routing or a working kill switch you are choosing the app path whether or not you were thinking about protocols.
On a phone the useful test is simple: bring up whatever you have, start something long-running like a large download or a call, walk out of range of your wireless network, and see whether it continues or restarts. Then check that your address changed to the one you expect and that nothing leaked in the interval, using the checks in how to check for a VPN leak.
The short version
Pick the system-integrated tunnel when reliability without supervision is the priority — an always-on configuration on a phone, a device you cannot install software on, or a managed setup someone else defined.
Pick the app-provided one when you want the features that only a client can implement, and accept that the client is now part of your protection rather than a convenience wrapper.
Decide it from how the device is used, not from the protocol names. Count how often the device changes networks and how long it sits idle between those changes: that determines how often the repair mechanism runs and therefore whether the trigger for it — your first outbound packet, or the operating system announcing an interface change — is something you will notice. A device that moves constantly and is used in short bursts exercises that difference many times a day. A device that moves rarely exercises it rarely, and the platform-integration question in the section above becomes the whole of the decision instead.