A VPN on an iPhone: What Happens Between Networks

On an iPhone the tunnel is not really the app’s. An app asks the operating system to create a VPN configuration, you approve it once, and from then on iOS owns and runs it. That matters because a phone is the device that changes networks most — Wi-Fi to cellular, one Wi-Fi to another, awake to asleep and back — and each of those changes tears the tunnel down and rebuilds it. What happens in the intervals is the part worth understanding, and it is not something any app can fully fix.

The configuration belongs to the system, not the app

An app on iOS cannot build a tunnel of its own design. It requests permission to install a VPN configuration through the interfaces the platform provides, and the platform does the tunnelling. There is no root access, no way to load a driver, and no way to reach below what the operating system exposes.

Three practical consequences. First, an app cannot offer a capability iOS does not have, however it is marketed — so claims that sound like they require deeper access than the platform grants deserve scepticism. Second, the configuration outlives the app: deleting the app can leave a VPN entry behind, and an entry can exist with nothing able to service it, which is why a phone sometimes shows a VPN switch that does nothing. Third, several apps can each hold a configuration, but only one tunnel runs at a time, and which one is active is a system setting rather than a race between apps.

Every network change is a teardown

A tunnel is built on top of a path, and when the path changes the tunnel has to be re-established. Moving from Wi-Fi to cellular is not a seamless migration; the address underneath the tunnel changed, and the session has to reattach or restart. Some protocols were designed to survive a changed underlying address and reattach quickly. Others rebuild from the beginning. Either way there is an interval, and on a phone that interval happens many times a day without you noticing.

Waking from sleep is the same event in a different costume. The phone suspended its radios, the connection it had is gone, and the tunnel comes back after the network does — not before it.

What leaves during the interval

This is the honest part, and it is worth stating plainly. Whether anything escapes while the tunnel is down depends entirely on whether the configuration is permitted to block traffic in the meantime, and on an ordinary personal iPhone that is not typically how it works.

iOS provides a facility for reconnecting a tunnel on demand, so that when the device tries to use the network the tunnel is brought up first. That narrows the window considerably and is worth having. It is not the same thing as refusing to send traffic while the tunnel is down. A genuinely enforced always-on state, where the device will not carry traffic outside the tunnel at all, is a managed-device facility — the sort of thing an employer’s device-management configuration imposes on a company phone — rather than a toggle in a consumer app.

So the realistic model for a personal phone is: mostly tunnelled, with brief unprotected moments clustered around network changes and waking up. That is a reason to be thoughtful about what you do in the first seconds after unlocking on a network you do not trust, and a reason not to treat a phone tunnel as equivalent to the fail-closed behaviour a desktop client can enforce.

It is also worth knowing that operating systems reserve the right to send some of their own traffic outside a user-installed tunnel. Read “all your traffic” as “all app traffic, subject to what the platform decides”, because that is what it means on every mobile platform.

The address underneath changes too

A tunnel replaces one address with another, and on a phone the one being replaced is unusually variable. On Wi-Fi you have a private address from that network and share its public one with everyone else on it. On cellular you were probably behind carrier-grade address sharing already, meaning the public address the internet saw was shared with a large number of other subscribers before any VPN was involved. Understanding that changes what a tunnel buys you on a phone: it is often less about hiding from the far end, which already saw a shared address, and more about the network operator in the middle.

The exit address changes too. Each reconnection may land on a different server, and services that tie a session to an address will notice — logging you out, prompting for verification, or asking you to confirm the sign-in. That is not a fault; it is the visible cost of an address that changes several times a day.

Removing it properly

Deleting the app is step one of two. Check whether a VPN configuration remains, and remove that too. A leftover configuration is not dangerous in itself, but it makes the phone’s state confusing: a switch that appears to offer a tunnel and cannot deliver one is exactly the sort of thing that produces false confidence later.

Where the platform genuinely differs from its sibling

If you use both mobile platforms, it is worth knowing that the trade-offs are not symmetrical here. The other major mobile platform exposes real system-level controls — including a switch that blocks traffic when no tunnel is up — and pays for it with more configuration surface and more vendor variation. That comparison is drawn out in the Android setup notes; the short version is that iOS gives you fewer decisions and less control over the failure case, which is a genuine trade rather than a defect. If you have not yet decided whether the phone is even the right place for the tunnel, start with the layer question.