What Does IncludeAllNetworks Do in a Mac IKEv2 Profile?

In a native IKEv2 profile the interesting key is not a checkbox, it is IncludeAllNetworks, and what it changes is the scope of what the system is allowed to send outside the tunnel. Set it to 1 and macOS treats the tunnel as the path for essentially all IP traffic, minus a set of exceptions it defines and you may extend. Because it lives in a profile dictionary rather than in a menu, it also does not mean what most people assume when they read the phrase send all traffic.

What the key changes inside the network stack

Without it, the tunnel behaves like a network interface with routes attached. A default route through that interface captures most traffic, and any more specific route on another interface still wins for its own prefix. That is normal routing, and it is why split tunnelling happens almost by accident.

With the key enabled, the scope stops being a routing preference and becomes a policy about which traffic is allowed to leave through anything other than the tunnel. The system still needs to reach the network to keep the connection alive, so the policy ships with exceptions rather than pretending they do not exist. Enabling it never leaves the machine with no working path at all. What you get is a shorter list of paths than you assumed, and that list is documented.

The practical consequence is that adding a route no longer explains the outcome. If a destination is still reached directly, the question to ask is not which route won but whether an exception covers it.

The exceptions are part of the setting

Apple documents several exclusions beside the main key, covering local networks, Apple Push Notification traffic, cellular services and device communication. Each has its own platform and version conditions, so the same profile can behave differently across macOS releases.

Some of those exclusions are intrinsic. Traffic needed to establish and maintain network access, including captive portal handling, has to be allowed or the machine can end up connected to nothing and unable to fix it.

Then come the deliberate choices. Allowing a home printer is not the same decision as allowing a work resource prefix, and both differ from leaving APNs reachable so notifications keep arriving. Record which ones you enabled, in the profile itself, rather than discovering them later from a bug report.

Why it is not the same as a default route

A default route is a routing table entry, and routing tables lose. A more specific prefix beats it, an application-scoped connection can bypass it, and a second interface with a better metric can take over without anyone touching the VPN configuration.

Apple's routing guidance makes the distinction explicit: ordinary defaults can be overridden by more specific routes, while the broader scoping setting defines which traffic the tunnel must carry and what is carved out of it. One is a preference, the other is closer to a rule.

That difference also changes how you diagnose a leak. With a default route you inspect routes and metrics. With the scoping key you inspect the profile revision, the installed exceptions and the version-specific behaviour, because the routing table is downstream of a decision made earlier.

EnforceRoutes is a different knob

EnforceRoutes sounds like the strict version of the same idea, and people stack the two in the belief that more keys mean more coverage. Apple documents that it is ignored when IncludeAllNetworks is enabled, so the second key buys nothing in that combination.

Treat it as an alternative for configurations that do not use the broader scoping, not as reinforcement. If you cannot explain what each key does on its own, adding both only makes the profile harder to review.

What the gateway and the profile owner must agree on

A client setting cannot make a server forward traffic it was never configured to forward. The gateway needs to accept the session, hand out addresses, provide a return path for the prefixes you intend to reach, and serve DNS in whatever arrangement you chose. If it only routes one prefix, the broad client scope produces traffic that arrives and dies. One request to a destination outside the gateway routes proves that in a minute.

An app-owned tunnel is a separate case again. The provider has to implement or expose the supported behaviour; installing a second native IKEv2 profile does not modify a tunnel that another app already manages, and an IKEv2 key is not an OpenVPN directive that some other client will read.

For the current key list and version conditions, read Apple's IKEv2 payload reference rather than a profile someone copied years ago.

Accept a profile revision as a whole

Before you change a remotely administered Mac, write down the target macOS versions, the intended internet exit, the private prefixes that must stay reachable, and every exclusion you are enabling. Then preserve a recovery path that does not depend on the tunnel you are about to alter.

Test fresh public requests, private requests, both address families and name resolution, and check the installed revision rather than the design file. If something still goes direct, decide whether it is a documented exception, a different connection context, or an actual configuration error, and change one of those three rather than widening unrelated keys.