How MOBIKE Keeps an IKEv2 VPN Alive When the Network Changes

A phone leaves Wi-Fi and joins cellular, a laptop moves from Ethernet to a hotspot, and the IKEv2 tunnel either survives or it does not. MOBIKE is the extension that lets it survive, by telling the far end that the source address changed instead of starting over. What it does not do is keep every application alive through the change. Those are two claims, and the second one is the one people usually mean.

Walk the transition in stages, because each stage fails differently.

What the update actually changes

While the security association is still valid, the initiator learns its new address and sends an update to the responder, which then uses that address for the same association. The security parameters are not renegotiated from scratch. That is the whole benefit: no new authentication round, no new key exchange, no user prompt. It also means the surviving state still belongs to the old session.

MOBIKE can also move traffic to UDP encapsulation, which is why a working tunnel sometimes starts using port 4500 after a network change. That transition does not by itself prove NAT was detected, even though the two often appear together.

Does your profile actually enable it

Both peers have to support the extension, and the deployment has to enable it. In strongSwan the behaviour is configurable per connection, and interface or route changes can trigger a path search and an update when needed. Inspect the connection's actual settings rather than assuming every IKEv2 profile turns it on. A profile copied from a guide that predates the feature is a common source of this.

The negotiated state on both ends is the authority, not the documentation for the product family.

Walk the transition in stages

Record the application's state before moving networks. Then move, and record the client and server state afterwards. A missing address, an unreachable peer and an application that must reconnect its own session are three different outcomes. Only the first two belong to the VPN layer; the third belongs to whatever protocol the application speaks.

Compare a network switch against a stationary test, so you know which event triggers the problem. A throughput measurement on the final network cannot reproduce a transition. It measures the destination, not the journey.

Separate the failure layers

A long-lived TCP session can fail for reasons outside the IKEv2 exchange. The new network may filter differently, resolve differently or route differently. The tunnel address may not change at all while the path underneath it does. That is why an application reconnect can fix something the VPN never broke.

Keep the blocking policy in place while you recover, too.

Automatic mobility and a rule preventing direct traffic are different controls, and disabling the second to make the first work is a bad trade. If the mobility update fails, the block should hold rather than leak traffic around the tunnel.

What to record when it repeats

Retain timestamps and both address values from both sides. That record shows whether the update completed before the application lost contact, which is the difference between a mobility bug and an application timeout. Then compare the switch direction: leaving Wi-Fi for cellular is not symmetric with the reverse. One direction can work while the other fails.

That asymmetry is common enough to be the first thing to test.

With the record in hand, the incident stops being another disconnected icon and becomes one event in a sequence with a known owner. Which is all a walkthrough can honestly promise.