Split Tunneling vs Company Policy: Which Rule Wins

Ticking one app in a split-tunnel client feels like a local preference, and on a managed device it is closer to a policy change. The exception moves traffic off the approved path, which may be the same path that carries managed DNS, filtering and the source address a service recognises. The client is not misbehaving when it reverts your edit; the deployment is doing its job.

Before arguing about the checkbox, work out which property the policy exists to protect.

The property behind the rule

Some deployments route everything so that all traffic passes an approved gateway. Others care about name resolution, keeping queries on the corporate resolver rather than the local network's. Others need a stable source address so internal services can decide whether to answer at all.

A fourth group enforces endpoint posture: disk encryption status, patch level, agent health. Splitting the tunnel does not change those, while a bypass that avoids the agent's own traffic can.

Those are four different requirements, and each is broken by a different exception. Read the requirement before proposing the change, because the person who wrote it can tell you immediately which one applies. A change that satisfies the wrong one buys nothing.

Two claims are worth discarding early. Full tunneling does not hand administrators every plaintext page, since application encryption and endpoint controls decide what is visible. Split tunneling is not universally unsafe either, because managed DNS, per-app policies and endpoint agents can hold regardless of the route.

Run the checks in order

The sequence below narrows an exception to the smallest thing that actually failed. Stop at the first check that does not hold, because a later fix cannot compensate for an earlier gap.

Ask which traffic now misses the approved gateway, then confirm that name resolution still reaches the corporate resolver. Check whether the application in question respects a kill switch, or whether it spent the failing attempt on a direct route. Then look at shared services: a document viewer or update broker can carry the exception further than the checkbox suggests. Finally, note whether policy reapplies on reconnect, because that behaviour decides whether any local change survives.

Each answer is a fact, and facts are what an exception request needs. An argument about whether the VPN is annoying is not one of them. Write the answers down before the conversation starts.

Ask for a narrow exception

Report the application, the destination and the operation that failed, in that order. A request to keep one updater on the direct path is reviewable; a request to bypass the tunnel for the whole browser is not.

Describe what you already tried and what the logs showed, and address it to whichever team owns the profile rather than to whoever answers the help desk. On a managed device the profile owner can usually create a supported exclusion that survives updates, while a local route edit cannot.

If the answer is no, treat it as a design decision and not as an obstacle to route around. The next review is the place to reopen it, with the failing operation documented and the business reason attached. Working around it risks more than the exception was ever worth.

Make the exception survivable

After an approved change, confirm the parts that were working before, not only the part that was broken. Internal names should still resolve through the corporate resolver, private resources should still answer, and the previously failing task should now complete.

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

The first command proves the resolver still answers for an internal suffix, and the second proves a request reaches the internal service from the current route. Run them again after a reconnect, because a policy push can quietly undo a change that looked stable during the test. Two lines of output stored with the ticket close the loop. Without them, the exception rests on somebody's memory of a page that loaded once.

Record the exception, its purpose and the components it covers in the same place as the deployment notes. An undocumented exception becomes next quarter's incident, and a documented one becomes evidence that the design handles a real workload.