WireGuard vs IKEv2: reconnects, roaming and battery

WireGuard and IKEv2 are the two VPN protocols that handle a phone's habits well: both keep a tunnel alive when you move from Wi-Fi to mobile data, and both are light on battery. WireGuard does it with a simpler design, a lighter handshake and the freedom to run on any UDP port. IKEv2 does it with MOBIKE, a standardised roaming extension, on two fixed ports that networks recognise. For a phone, WireGuard is the better first choice and IKEv2 is a sound fallback.

What the two have in common

Both run over UDP, so neither suffers the stacked-retransmission problem of a TCP tunnel. Both use modern authenticated encryption, typically ChaCha20-Poly1305 or AES-GCM. Both were designed with the assumption that the client's address will change, which older protocols were not. And both establish a tunnel in a small number of round trips: one for WireGuard, two for IKEv2.

Where they differ

Reconnects and roaming

The reason both are good on phones is that neither treats a change of address as a failure.

WireGuard has no notion of a connection to lose. The server identifies a client by its key, so when a packet arrives from a new address and decrypts correctly, the server simply starts replying there. No message says "I have moved"; the move is implicit in the next packet.

IKEv2 gets the same effect through MOBIKE, defined in RFC 4555. When the phone's address changes, it sends an UPDATE_SA_ADDRESSES notification, the server verifies it, and the existing security associations continue on the new address. It is a little more machinery than WireGuard's approach, but the outcome for you is the same: the tunnel follows the phone.

In both cases the phone still has to notice that the network changed and send something. On Android that notification arrives from the system, so the gap is usually well under a second on either protocol. The post on VPNs that keep disconnecting covers what happens when the system kills the app instead.

Battery

Idle behaviour is where they diverge slightly. A WireGuard tunnel with nothing to send sends nothing, so the radio can sleep. If the phone is behind a NAT and the server needs to reach it, the app can enable a persistent keepalive, typically every 25 seconds, which the keepalive post explains. IKEv2 has built-in dead-peer detection and, behind a NAT, its own keepalives, so it is rarely completely silent. In practice both are frugal, and the difference over a day is smaller than the effect of a distant server or a poor signal.

The handshake matters more than idle traffic on a phone that reconnects often. WireGuard's is one round trip and a few hundred bytes. IKEv2's is two exchanges, and when certificates are involved the IKE_AUTH messages can be several kilobytes and fragmented across multiple packets. Each reconnect costs IKEv2 more time and radio than it costs WireGuard.

Ports and getting through

WireGuard can listen on any UDP port, so a server can offer it on 51820, on 443, on 53, or on all three, and a phone can try each. IKEv2 is defined on UDP 500 and 4500 and nowhere else. A network that wants to stop IKEv2 needs only to drop those two ports, and many restrictive networks do. That makes IKEv2 a weaker fallback than it first appears: any network that lets IKEv2 through will almost always have let WireGuard through on one of its ports already. It earns its place at the bottom of the list rather than the top.

On Android specifically

WireGuard runs inside the app, through Android's VpnService, so the app owns the tunnel and can watch every packet and every counter. IKEv2 on recent Android can use the operating system's own client, which is efficient but gives the app less visibility: it has to confirm the tunnel is actually carrying traffic by sending a request through it rather than by reading counters. A careful app does that check either way, and the handshake post explains why proof of traffic matters more than a "connected" label.

Culvert VPN tries WireGuard over UDP first on several ports, then a TLS-wrapped transport on TCP port 443, and reaches IKEv2 only as its last attempt, with the choice made automatically and never shown as a protocol name; it is on Google Play.