Apple IncludeAllNetworks: What Still Bypasses the VPN

You open the profile in the MDM console, see IncludeAllNetworks ticked, and assume every packet from that device now enters the tunnel. Apple's own schema does not promise that. The setting routes traffic through the VPN with exclusions, some of them optional switches and some required for the system to keep working at all. The walkthrough below follows that document outward from the profile, so the first thing you read is the setting itself rather than a capture from a device nobody has identified yet.

Two of those exclusions account for most of the confusion, and both involve cellular service.

Start in the managed profile, not in a capture

Open the managed VPN profile schema and read the property description before you read any packet log. Note that the description is about routing with exclusions, not about a full tunnel guarantee. That single sentence decides how you interpret everything you see afterwards.

Write down three things while you are in the console: the payload identifier that carries the setting, the managed OS release on the device, and which VPN implementation is actually installed. A key being described in documentation says nothing about whether a third-party client exposes it in its own configuration UI.

Read the cellular exclusion as two different cases

In supported configurations, ExcludeCellularServices excludes internet-routable cellular-service traffic, but only when it is enabled alongside IncludeAllNetworks. The schema gives Wi-Fi Calling, IMS and messaging-related services as examples of that category. Those flows can leave the tunnel by design, and no amount of profile review will route them through it while the exclusion is on.

The second case is separate and does not depend on any switch. Some carriers deliver cellular services directly over their own network rather than through the internet, and Apple documents that category as always excluded from the tunnel. It is not the conditional internet-routable case above, so a profile that clears every exclusion box still will not capture it. Treating the two as one feature is where most arguments about a leak start.

If your requirement is literally that no packet ever leaves the tunnel, this second case already makes that requirement impossible on a cellular device. You need to know that before the design review, not after it.

Check the keys your platform actually exposes

The schema also describes necessary network-connection and captive-network traffic, plus separate controls for other categories such as local networks and device communication. Those are documented configuration relationships, not observations of your device. Confirm each one against the OS release you manage, because availability changes between releases and a profile key that is silently ignored looks exactly like a profile key that is doing its job.

A minimal payload for this decision usually looks like this, with the cellular flag explicit rather than inherited from a template:

<key>IncludeAllNetworks</key><true/>
<key>ExcludeCellularServices</key><true/>
<key>ExcludeLocalNetworks</key><true/>

If a key is missing from the delivered profile, the device falls back to that key's default, which is not necessarily the value the template author had in mind. Diff the delivered payload against the template rather than reading the template alone.

Work out what an unfamiliar hostname is

When a suspicious name shows up, establish what the observation actually represents: a name the system requested, the resolver that answered, a connection destination, or a label a tool printed. A carrier-related name on its own identifies neither the originating process nor the exception that applied. Chasing it as proof of a bypass is how a support thread spends a week on the wrong layer.

Use supported diagnostics and talk to the administrator who owns the profile, then compare the flow against the intended policy. That comparison, not the hostname, tells you whether the traffic was expected.

Resolve the requirement instead of weakening the system

Do not install an unexplained root certificate or disable system services just to make a capture quieter. Quieting the capture removes the evidence and leaves the exclusion in place, which is a worse place to end up than the original question. If a compliance rule forbids a category the platform deliberately excludes, take that conflict to the device and network owners with the schema section in hand.

Close the walkthrough by recording which exception explained the traffic, the OS release it applies to, and the profile value that produced it. A connection icon cannot reconcile two incompatible assumptions about how far the operating system's traffic scope extends.