Your iPhone VPN Lock Is a Policy, Not the Protocol

The VPN icon shows connected, the tunnel drops for a moment during a network change, and traffic that should have been blocked goes out over cellular. Nothing in the interface announced a gap. The feature you were relying on is a client and platform policy, and a protocol name in the settings does not describe what happens during that second.

Describe the lock as a contract about states, not as a property of IKEv2 or On Demand.

The symptom: the icon says connected

An icon reflects the client's view of its own state, and that view can lag reality by the length of a reconnect. A cached page, a fast reconnection or a status refresh all hide the interval. The question worth asking is not whether the icon was green, but what the device permitted while the tunnel was absent. The same lag explains why a screenshot of the app is such weak evidence: it records a state, not a transition.

That question has an answer only if the policy defines it.

What the protocol actually maintains

IKEv2 maintains and renews an authenticated IPsec relationship, and mobility features help restore it after an address change. That is a statement about the tunnel's lifecycle. It says nothing about the iPhone's permission to send other traffic in the gap, because that permission belongs to the platform and the client, not to the key exchange. A device that reconnects in under a second still had a window, and the window is where the interesting behaviour lives.

On Demand is similarly a description of activation behaviour, not a universal blocking guarantee.

What the platform offers a developer

Apple's Network Extension exposes traffic-scoping controls, and its routing guide distinguishes include-all-networks behaviour from ordinary included routes and lists the system exceptions. A supervised Always On deployment model also exists, separate from a personal app's automatic-connection setting. Whether a given app uses any of that is a property of the app, not of the protocol it speaks.

A toggle's name is not evidence of which API the app calls.

Read the feature as a contract

Ask the provider to specify five states: initial activation, unexpected tunnel loss, deliberate disconnect, app exit and device restart. Put the system exceptions and any intentional LAN access next to that list. Then ask whether the feature is optional, management-enforced, or conditional on a client mode, because a user-facing pause and an organisation's enforced lock are different products. Write those five answers into the deployment record, since the next reviewer will ask exactly those questions.

A feature that blocks on unexpected loss but not on a deliberate disconnect is a coherent design. It is just not the one the marketing page described.

How to test the gaps

Test one transition at a time with harmless traffic, in the app and address family you care about. Confirm what was permitted during the gap, not what the icon showed afterwards. Record the client version and the policy alongside the result, because both change and neither is visible from the phone's settings screen. That is the only way to separate a real gap from a slow icon.

If the answer matters for compliance, ask for it in writing rather than inferring it from a product label.