Always On VPN vs VPN On Demand on iPhone: What to Deploy

On Demand starts a tunnel when its rules match; managed Always On enforces coverage on supervised devices. A runbook for choosing one and proving it works.

Two iPhones can both say VPN and behave nothing alike. On Demand opens a tunnel when a rule matches, and the user can still turn it off in Settings. Managed Always On keeps coverage enforced on a supervised device, including the moments when the tunnel cannot come up. Pick by asking what has to be true when the user does nothing, then test the transitions rather than the steady state. The steps below run in the order a deployment actually fails.

Step 1: establish what the device can enforce

Always On is a supervised-device feature. If the fleet is not supervised, the discussion is over before it starts, and no payload key turns an unsupervised phone into an enforced one. Confirm supervision from the management side and from the device, then confirm who signed the profile.

On the phone, open Settings, then General, then VPN & Device Management. The profile entry names its owner, and a manually installed personal profile looks different from one delivered by a management service. Do not infer enforcement from the profile's name or from a provider's marketing label; the label is not the platform policy.

Write down three facts before touching configuration: supervised or not, managed profile or personal, and which client implementation carries the tunnel. Every later step depends on those three, and transferring behaviour from a personal phone to a managed profile is how a deployment gets signed off against the wrong baseline.

Step 2: read the on-demand rules instead of the feature name

On Demand is a list of rules, evaluated in order. Each rule names an action and the conditions that select it, and the conditions are the interesting part: interface type, Wi-Fi SSID, DNS domain suffix, or a probe URL. A rule set that never matches is a feature that never connects.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Read the whole array and ask two questions per rule: can this condition ever be true on this fleet, and what happens when no rule matches? Enterprise networks rename access points, merge SSIDs and change DNS suffixes, and each of those edits silently detaches a rule from reality.

A DNS-suffix condition is the one most often wrong in the field, because the suffix a phone reports on a guest network is not the suffix the corporate resolver serves. Verify the name the device actually resolves before trusting the rule.

Step 3: test the transitions, not the static connection

A tunnel that is up while you look at it proves very little. Run each transition deliberately and record what the device does, using the same private resource every time so the results are comparable:

  • Join a network where a rule should match, then request the private resource and confirm it loads.
  • Switch to cellular with the app in the background, then foreground it and repeat the request.
  • Connect to a captive-portal Wi-Fi and see whether the portal is reachable or whether enforcement blocks it before you can authenticate.
  • Disable the tunnel manually on a supervised device and check whether it comes back on its own, and how quickly.

Run the same list on an unsupervised device if you have one. The difference between the two results is the deployment's real behaviour, and it is the part a screenshot of a connected tunnel never shows.

Step 4: know the two failure shapes

Enforced coverage fails by blocking. When the tunnel cannot establish, the device loses ordinary internet access along with private resources, and the user experiences a phone that is online but cannot browse. Reconnecting and blocking are separate observations, so log both instead of treating "no internet" as one symptom.

On Demand fails by not triggering. The rule does not match, no tunnel appears, and the private resource simply times out. This one is easy to misdiagnose as a server problem, because the client is behaving exactly as configured.

A captive portal sits between the two: it needs connectivity before the tunnel exists, so a policy that blocks everything until the tunnel is up needs a documented path through the portal. Decide that in the design, not at the help desk.

Step 5: verify, then rehearse the rollback

Verification belongs on the real path with harmless traffic: request a private resource that must not be public, confirm which address the device presents to the outside, and repeat after a reboot so you have seen the startup sequence rather than only the warm state.

Then practise removal on a test device before you ever need it in production. Removing the profile returns the device to its previous state, and knowing how long that takes and what the user sees is part of the runbook. Apple's VPN security guide is the reference for what the platform documents about these policies, and it is worth reading before writing a configuration that asserts more than the platform does.

Keep the three facts from step one next to the rule set and the test results. When the next person asks why a phone connects on one network and not another, those notes answer it in a minute instead of a rebuild.

Mikanda mikatakata