Full tunnel vs split tunnel: the four things that differ
The label decides where the rest of a laptop traffic exits, not how fast it is. Compare egress, load, DNS and failure behaviour before choosing.
Tunnel labels describe where the rest of a laptop's traffic goes, not how fast it goes. With a full tunnel, public requests traverse the VPN gateway before leaving for the internet. With split tunneling, private destinations use the tunnel and everything else takes the local path. Both reach the internal application, so the reachability test people run first says nothing about which policy is deployed.
Test the exit instead: which address a public echo page reports, and which resolver answered.
Myth: split tunnel is just the faster option
Split tunneling is often sold as a performance feature, and it can be one, but that is a side effect rather than the definition. The definition is a routing decision about which destinations enter the tunnel. The speed difference appears only when the direct path is genuinely better than the detour through the office. On a congested home link and a lightly loaded gateway, the full tunnel can be the faster of the two.
So the honest framing is about path ownership and control, with performance as something you measure afterwards. A policy chosen for speed that silently moves your DNS and public egress was chosen for the wrong reason.
What actually changes: the exit
Under full tunnel, a public website sees the office egress address and the office filtering sees the request. Under split tunnel, the same site sees the user's home address and the office sees nothing. Those are different visibility models, and neither is automatically safer. The useful question is which one the organization can actually operate.
Check it directly rather than trusting a Connected badge. A public address echo shows the exit, and a resolver test shows whose DNS answered.
| Question | Full tunnel | Split tunnel |
|---|---|---|
| Public exit address | Office egress | Local connection |
| Gateway load | All covered traffic | Private destinations only |
| Office visibility | Requests and destinations | Private resource access only |
What the gateway then has to carry
A gateway carrying video calls, downloads and private applications needs capacity for a very different workload than one carrying only internal requests. The site's internet connection carries both the user's arrival and the subsequent public egress, so two links can saturate at once.
Local breakout removes that load and the detour, and it does not guarantee a better experience, because the direct path can be congested too. Compare the actual application rather than treating a routing label as a performance measurement.
Exceptions exist under a full tunnel
A default route is not an inventory of every packet. More specific routes, local-network allowances, application exclusions and separate IPv6 rules all move traffic, which is why a policy described as full tunnel can still leak. The operating system's routing documentation draws that distinction for force-tunnel defaults, and the client's exception list is where the leak usually lives. Verify behaviour, not intent.
IPv6 deserves its own look, because a tunnel that carries only IPv4 leaves an entire stack outside the policy.
DNS is a separate policy
Internal names need a resolver that knows them, and that resolver may be reachable only through the tunnel. A browser with its own encrypted DNS can bypass the system resolver entirely, which produces a split where internal names fail and public ones work, or the reverse.
Decide where lookups should go, then make the client and the browser agree. Successful public browsing never tests internal name resolution, so it is the wrong evidence to cite when an intranet site goes missing.
Write the failure policy, then test it
Decide what happens when the tunnel drops: block everything, block only private resources, or allow direct connections. Automatic reconnection does not answer that question, and a kill switch that only covers the tunnel interface can leave excluded applications talking freely. Test a real disconnect and a network change, then read the client's state, because the documentation describes the intended behaviour rather than the installed one.
Record the private routes, the public exit, the DNS servers, the local exceptions and the failure behaviour in one short note. That note is what makes the policy verifiable by someone who did not write it.