iPhone on-demand VPN dials in on office Wi-Fi, not cellular
Your exclusion rule exists and still loses. On-demand lists are read top down, so one early catch-all decides the morning before the office rule is seen.
Nine o'clock, the phone joins the office wireless, and the tunnel comes up by itself and stays there all day. Cellular later behaves exactly as everyone intended. Somebody added an exclusion for the corporate network weeks ago, so the profile reviews clean, and every morning still produces the same result. The device is following the list it was given, and the list says something other than what its author believed.
The list is read from the top, and the first match wins
Entries are evaluated in order. The first one whose conditions hold decides the outcome for that moment, and everything below it never gets a look. Order therefore carries as much meaning as any condition written inside a rule. Reading the array from the top explains a profile that appears to ignore an exclusion it clearly contains.
A general wireless connect entry placed above the office exclusion guarantees a tunnel on site. Nothing else in the payload has to move for the behaviour to flip.
A Disconnect entry does two jobs
When the action is Disconnect, the entry closes a session that already runs and blocks a new one while its conditions remain true. Both halves matter for an exclusion, and the second half tends to be forgotten. The same entry in a second profile explains a floor where the VPN refuses to start while the rest of the building works. Nobody touched the tunnel; the list did.
The table shows the shape of it, exclusion first, with names that have to come from your own deployment. Two entries usually carry the day, and a third for cellular keeps the rest of it predictable.
| Order | Action | Conditions |
|---|---|---|
| 1 | Disconnect | Wireless interface plus office network name |
| 2 | Connect | Wireless interface |
| 3 | Connect | Cellular interface |
Keep both conditions on the exclusion
Pair the network name with the interface type. A name on its own can fire on a tethered link carrying the same label, while an interface type on its own excludes every wireless network the user visits that day. Both halves belong to one entry, not to two rules that happen to sit next to each other.
The name comparison is exact and case-sensitive. That suits one known network and strains everywhere else, because guest networks reuse familiar labels, sites get renamed after a merger, and a wired desk carries no name at all. Ask the network team for the exact label rather than reading it off a wall sign.
When a probe beats a name
A probe entry requests a URL and reads a successful answer as the condition being true. Choose a host that answers only from inside, such as an intranet service that cannot resolve publicly, and the rule stops caring what the network calls itself. A probe that answers from anywhere tests the internet rather than the building. The property that decides whether this works is the answer arriving without a redirect; a guest portal that bounces every request turns the probe into noise.
Domain-based rules are a separate form: NEEvaluateConnectionRule matches requested domains and can connect when a name is looked up. Its wildcard is accepted only as the left-most label, so *.example.com is valid while example.*.com is not. If a profile uses neither interface conditions nor reachability probes, check whether it is using that rule type instead.
What on-demand rules do not control
Rules choose whether a tunnel starts and have no say in keeping it running. A session that appears and then vanishes minutes later points at idle timers, gateway session limits or the path size. Each of those leaves a different trace, which is the reason to eliminate the rule list before changing any of them. Keep-alive settings do not explain that pattern, and changing them relocates the work without touching the cause.
Users can turn on-demand off in Settings, and a managed assignment can restore it at the next check-in. When the toggle keeps drifting back to its previous position, the assignment is the active party. The distinction matters, because enforcement comes back on its own while an offer stays off.
Confirm which profile group owns the device and whether the intent is to enforce the tunnel or merely to offer it. That answer decides whether the user preference counts as a bug or as a feature.