iPhone VPN After a Restart: What Should Happen First
Turn keep-the-VPN-on into a startup requirement: what connects, what still needs you, and what is blocked before the first protected task runs.
"Keep the VPN on" survives about thirty seconds of questioning. On after a restart? On before you unlock the phone? On while the Wi-Fi still shows a sign-in page? Blocking traffic until it comes up, or letting the first app try direct? Those are four different requirements, and only some of them are things a phone can be configured to guarantee. Write the answer as a timeline with stages, then check each stage after an actual reboot.
| Stage | Personal profile | Supervised Always On |
|---|---|---|
| Before first unlock | do not assume a tunnel | do not assume a tunnel either |
| After unlock, network up | depends on the provider or On Demand rule | activates without user interaction |
| Tunnel negotiating | first app may already be trying | policy decides whether traffic waits |
| Gateway unreachable | usually falls back to whatever the client allows | follows the deployed policy |
Write the requirement as a timeline
Start with the moment that matters to the business: which protected task must not happen without a tunnel, and how long after boot is that task realistically attempted. Everything before that moment is a sequence, and the sequence is what you verify. A note that says "VPN must be on" cannot be tested, while "no traffic to the records host before the tunnel is established" can.
Then separate what a personal phone can do from what a supervised fleet can do, because the two answers are not interchangeable.
Step one: the state before the first unlock
Do not infer pre-unlock behaviour from a tunnel you saw after unlocking. The honest test is to reboot, leave the phone locked, and observe from the other end whether any tunnel forms. For most personal arrangements the answer will be no, and that is not a fault; it just means the first protected task must not be attempted before the phone is unlocked.
If a requirement genuinely depends on coverage before unlock, take it to the deployment owner rather than to a client setting.
Step two: network readiness and captive portals
Supervised Always On activates without user interaction and persists across restarts while its profile stays installed, and establishment follows the interface gaining IP reachability. That last phrase is the important one: a phone that has not obtained an address yet has nothing to build on. A hotel portal that has not been accepted is a network that is not ready in exactly this sense, and no remembered VPN preference completes it for you.
So the acceptance note needs a line for the portal case. Either the phone waits, or a user taps through the portal first, and which one is acceptable depends on who is travelling. Write the choice down, because the person rebooting at seven in the morning will not invent it. A portal that requires a room number is also a different case from one that only accepts a checkbox.
Step three: authentication that still needs a person
Automatic activation and automatic authentication are separate capabilities. A profile using a device certificate can complete the latter without a human, while a gateway that demands a one-time factor cannot, and no policy will make it. Establish which of the two you are deploying before you promise a hands-free boot sequence.
Then note the intermediate state explicitly: if authentication is pending, is traffic blocked, queued or sent direct? The answer belongs in the plan because it is the window where a misconfiguration becomes a leak. Test it by making the gateway unreachable and watching what the phone does, rather than by reading the client's own description of itself.
Step four: the first protected task, then a transition
After the planned restart, open the protected task and confirm it succeeds and that it actually used the tunnel. Then repeat the same task across a Wi-Fi to cellular transition, because that move renegotiates the underlying network and is where a profile that only worked at boot starts failing. Record three facts for each run: whether the connection came up automatically, whether you had to authenticate, and whether the expected resource answered.
If protection during the gap is mandatory, use the verification method the deployment owner approves. A single successful page load cannot show that nothing went direct before it.