Split Tunnelling Gives You Two Paths Out of Your Device

Split tunnelling means your device has two working paths to the internet at once — one through the VPN tunnel, one straight out through your local network — and a rule set that decides which path each piece of traffic takes. Rules are usually written either by application or by destination. It solves real problems, and the price is that “am I protected right now” stops having a single answer and becomes a question about the specific traffic you have in mind.

Everything difficult about the feature follows from that, including the part where name resolution stops behaving the way you assumed.

Two paths, seen from the routing table

Without a split, one default route captures everything. With a split, you are maintaining exceptions.

An ordinary VPN connection installs a default route pointing at the tunnel interface, and your device sends anything without a more specific match there. That is why a full tunnel is simple to reason about: everything goes one way.

Destination-based splitting changes the routing table itself. Either specific prefixes are routed out the local interface while the tunnel keeps the default, or the tunnel is given only specific routes while the local interface keeps the default — “everything tunnelled except these” versus “nothing tunnelled except these”. You can read the result off your own machine, per how to read your own network settings.

Application-based splitting cannot work through routes alone, because a route matches a destination and knows nothing about which program produced the packet. It needs the operating system to attribute a socket to a process and apply policy accordingly, and that capability varies by platform — which is why app-based split tunnelling appears in some clients on some systems and is absent from the same client elsewhere.

What people genuinely use it for

Four cases where a full tunnel is the wrong shape.

Services that refuse tunnelled connections. Banking sites, government portals, and some streaming platforms treat a known VPN address as suspicious and respond with extra verification or a refusal. Routing those destinations locally is often the only way to use them without friction.

Local devices and services. A printer, a network drive, or a home automation hub sits on your local network, and a full tunnel can make them unreachable. Excluding the local subnet is such a common need that many clients do it by default.

A single application that must not be tunnelled. Work software with its own tunnel, a game whose matchmaking dislikes the exit address, a backup client sending a large amount of data.

The reverse arrangement, which is the more privacy-conscious one. Tunnel only the browser or only one application, and leave everything else on the ordinary path. This narrows what the VPN provider sees to the activity you actually wanted routed through them, rather than handing them everything your device does.

The cost, stated plainly

You now have to know which path each thing uses, and the answer can change without you doing anything.

Destination rules bind to addresses. A service that resolves to a different address than it did last week, or that is spread across a content delivery network with many addresses, may partly match your rule and partly not. Rules written as domain names are resolved into addresses at some point, and traffic that goes to an address the rule never learned about takes the other path.

Application rules bind to programs, which is coarser than people expect. Excluding a browser excludes everything you do in that browser, and including one application does not necessarily include the helper processes it spawns, the system service it delegates to, or the separate updater talking to the same servers.

There is also a kill-switch interaction that catches people out. If excluded traffic is meant to leave outside the tunnel, blocking all non-tunnel traffic when the tunnel drops would break it — so clients must decide whether the switch covers excluded traffic, and they decide differently. A split configuration can quietly turn “fail closed” into “fail closed for some of it”; the mechanism is in how a kill switch fails closed.

And the exposure is asymmetric. Traffic on the local path shows your real address to its destination and shows the destination to your internet provider. One misplaced exception does not weaken the tunnel; it removes the tunnel entirely for that traffic.

DNS is where this surprises people

Name resolution is usually a single system-wide setting, and it does not split neatly.

Your device generally has one set of resolvers in effect at a time. A VPN client typically replaces them with resolvers reachable inside the tunnel so that lookups are not visible to your local network. Now add a split, and ask a simple question: when an excluded application looks up a hostname, which resolver answers?

Both answers are wrong in some way. If the tunnel’s resolver answers, the fact that you visited that site goes to the VPN provider even though the traffic did not — and if that resolver returns an address suited to the VPN server’s location, your excluded application may be sent somewhere unhelpful. If the local resolver answers, lookups for tunnelled traffic are visible outside the tunnel, a DNS leak by any definition even though the traffic itself is properly encapsulated.

Better clients handle this with per-interface or per-application resolver policy, and it is one of the more common places implementations are imperfect; the general behaviour is set out in what your VPN’s DNS setting actually changes. The local cache adds its own confusion when a name resolved on one path is reused on the other, which is why clearing it resolves so many odd split-tunnel symptoms.

There is one more disclosure that no split configuration fixes. Even a correctly tunnelled connection announces its destination hostname in the opening handshake, so the parties who can see the tunnelled path still learn names, as explained in what still names the sites you visit.

Setting it up so you can verify it

Keep the rule set small enough to hold in your head, and check it after you write it.

Prefer the fewest possible exceptions, written in whichever direction produces fewer of them: six exclusions from a full tunnel is harder to audit than one inclusion into an otherwise untunnelled device. Keep the reason for each exception written alongside it, in the client’s own comment field if it has one, because an exception with no recorded reason cannot be evaluated later — you can see that it exists but not whether it should.

Then verify each side. From an application you expect to be tunnelled, confirm the apparent public address is the VPN’s; from one you expect to be excluded, confirm it is your own. Check name resolution separately, since it can be on a different path, and re-check after a client update because rule formats and defaults change.

Whether to use it at all

Use it when a specific service or device forces your hand, which is the honest majority of cases. Fixing one banking site or reaching one printer is worth the small amount of complexity.

Use it in the narrow direction if your goal is to limit what the provider sees — tunnel the one application whose traffic you wanted moved, and stop routing the rest of your device’s chatter through a company you are trusting on their word.

Avoid it if you could not say, later, which path something was on. A full tunnel with one clear answer is safer than a split you have half-forgotten, because the failure mode of a forgotten exception is complete exposure for that traffic rather than partial protection.