Split Tunnelling: Choosing What Goes Through the Pipe

Split tunnelling is the feature that lets you point at an application and say: not you. Everything else goes through the tunnel; that one goes out the front door. It solves real problems — printers, banks, work VPNs, the smart TV — and it introduces one that people rarely notice until it has been true for months.

Three flavours, which behave differently

App-based. You choose programs. The client hooks into the network stack and routes each process's traffic based on which binary opened the socket. This is what most consumer clients mean by the feature, and it is the most intuitive — until an app spawns a helper process, or a browser fetches something on behalf of a page, and the rule applies to the wrong thing.

Route-based. You choose destinations: addresses, subnets, sometimes domains. Traffic is sorted by where it is going rather than who sent it. Less friendly, considerably more predictable, and the only version that behaves sanely on a router.

Inverse. Everything goes out normally except the apps you nominate, which go through the tunnel. Useful when the VPN exists for one narrow purpose, and much safer to reason about, because the default is "not protected" and you are unlikely to forget that.

Whichever your client implements, read its documentation rather than assuming. The names are not standardised and the difference between "these apps use the VPN" and "these apps skip the VPN" is one checkbox and an entirely different security posture.

The problems it genuinely solves

• Local devices. Printers, NAS boxes, casting, the router's admin page. A full tunnel plus a strict kill switch can make the machine three metres away unreachable. Excluding the local subnet fixes it and costs nothing — that traffic never leaves the building.
• Banks and payment flows. Financial services score logins on address reputation, and a data-centre IP in another country scores badly. Excluding the banking app avoids a fraud hold. The traffic is end-to-end encrypted anyway; what you are giving up is hiding the fact that you use that bank from your ISP.
• Work VPNs. Two tunnels fighting over the default route is a losing evening. Excluding the corporate client is usually the only way to run both.
• Speed-sensitive traffic. Game clients, video calls and large downloads that gain nothing from the tunnel and lose latency to it.
• Services that block VPN exits outright. Streaming platforms, some ticketing sites, some government portals.

The two ways it quietly costs you

DNS often does not split. This is the sharp edge and it is implementation-specific. Many clients keep a single system-wide resolver regardless of the routing rules, so an excluded app may still resolve names through the tunnel — or, considerably worse, a protected app may resolve them outside it, announcing to your ISP exactly which sites you are about to visit privately. Test rather than trust; how to test properly is a short read and this is precisely the case it catches.

You will forget. A rule added in March to fix one printer is still there in November, quietly routing something around your tunnel every day. Nothing reminds you. The client does not warn you. The exclusion list is the single most neglected setting in any VPN app, and it is the one that most directly undoes what you are paying for.

The mitigation is unglamorous: keep the list short, write down why each entry is there, and read it once a quarter.

Setting it up without hurting yourself

1. Start from a full tunnel. Exclude only in response to something actually breaking. Do not pre-emptively exclude apps you think will be slow.
2. Prefer excluding destinations over excluding apps where the client allows it. "This bank's domains" ages better than "this browser", which is a rule with a browser-shaped hole in it.
3. Never exclude a browser. A browser is not one activity. Excluding it excludes everything you will ever do in it, which is most of what you wanted protected.
4. Check what the kill switch does to excluded apps. Sensible clients let excluded traffic continue when the tunnel dies, since it was never protected. Some block everything. Both are defensible; you want to know which you have.
5. Verify. Load an address-checking page in the excluded app and in a protected one. Two different addresses means it works. The same address means one of the two rules is not doing what the settings screen claims.

On routers, this is the only sane approach

Router-level VPN is where split tunnelling stops being a convenience and becomes the design. Every device in the house behind one tunnel means the TV cannot reach regional catch-up, the console picks bad matchmaking servers, and one weak CPU is trying to encrypt an entire household's traffic.

Policy-based routing by source device — this IP goes through the tunnel, that one does not — is the standard answer, and it is why the route-based flavour is the one that matters on network hardware. It also means the exclusions live in one place you can actually audit, rather than scattered across six clients on six devices.

Worth remembering

Split tunnelling is not a weakening of your VPN. It is an accurate statement of what you wanted protected, written down where the software can read it.

The danger is never the feature. It is the gap between the statement you made months ago and the one you would make today.

Questions people actually ask