iPhone IKEv2 Traffic Scope: Who Owns the Coverage Decision

You are looking for a Send All Traffic switch on an iPhone and it is not there. On a native IKEv2 profile the routing scope is decided by the profile that was delivered, not by a control the user can flip, so hunting through Settings for the missing toggle wastes an afternoon. The right move is to ask the profile owner for the traffic contract in writing, then verify it with real requests. This runbook does that in five steps.

Get the contract in writing before you look at the phone

Four outcomes need separate answers: whether internet browsing is meant to use the gateway, whether only private resources should, which local networks and system services stay outside the tunnel, and what happens while the tunnel is unavailable. Those are different requirements and they are satisfied by different keys. A profile that covers everything and a profile that covers one subnet can look identical on the device summary screen.

Also establish who owns the profile. If it was delivered by a management service, the values live in that console and a hand edit on the phone is a temporary local change at best. If nobody can name the owner, treat that as the finding and stop; guessing at coverage from the phone will not produce a supportable answer.

Ask for the four values that decide scope

The coverage key is IncludeAllNetworks, documented by Apple as introduced in iOS 14, and it is what makes the connection carry traffic broadly rather than only to the addresses the gateway pushes. The local exception is ExcludeLocalNetworks, available from iOS 14.2, and its documented iOS default is 1, which differs from the macOS default of 0. Ask which value each key carries in the actual payload instead of assuming a platform default from a Mac-oriented guide.

Then ask about DNS, because which resolver receives private and public names is part of the same contract and has its own reachability requirement. A tunnel that carries all traffic but leaves private names with a public resolver will look like a broken tunnel to every user who types a short hostname. Test that case first, because it is the cheapest one to reproduce and the one users report as "the VPN is broken".

Check the version floor before you sign off

Each of these keys has a minimum release, and a profile carrying a key the installed iOS does not know is not a partial success. Additional exclusion keys covering push notifications and cellular services carry their own floors as well, so a payload assembled for one fleet can half-apply on an older one. Record the installed iOS version next to the payload version in the deployment record. A payload that half-applies is worse than one that refuses to install, since the device reports a tunnel you cannot reason about.

Do not install an unidentified profile just to reveal a control that a screenshot from an older release promised. If the supplied configuration does not include a key, the key is not in effect, whatever the summary screen suggests.

Verify with traffic, not with a switch position

After provisioning, open the intended private resource and an ordinary public page, and confirm both take the path the contract describes. Then put the phone on cellular, repeat both, and check the behaviour you documented for the unavailable case rather than inventing it during the test. Include one permitted Wi-Fi to cellular transition, because that is where a profile with a narrow scope usually shows itself.

Keep a supervised managed Always On deployment out of this comparison. Automatic activation and broad routing on a personal profile do not establish that managed policy, and the reverse is also true. Test one arrangement at a time on one device, because a phone carrying two VPN profiles will confound every result you collect.

Roll back to a known profile

When the behaviour is wrong, remove the profile and reinstall the last known-good payload rather than editing keys on the device. Then confirm that the previous coverage is really back by repeating the same two requests. A rollback that restores the profile but not the routing is not a rollback, and it will be discovered by a user rather than by the test.

File the payload version, the four values and the verification result together, so the next change starts from a documented baseline instead of a screenshot.