Full-tunnel VPN use routes every single piece of a device’s internet traffic through the encrypted VPN connection without exception. Split tunneling offers a middle ground, letting you specify that certain applications, destinations, or types of traffic bypass the VPN entirely and connect directly, while everything else still routes through the encrypted tunnel as normal.
Why anyone would want less protection, selectively
The appeal of split tunneling is not that VPN protection is unnecessary for some traffic, it is that full-tunnel routing creates real practical friction in specific situations. The clearest example is accessing devices on your own local network, such as a printer, a smart home hub, or a network-attached storage drive, while connected to a VPN. Because a full tunnel routes all traffic through a remote VPN server, your device effectively appears to be somewhere else entirely on the internet, which typically breaks its ability to reach devices on your own local network directly. Split tunneling lets local network traffic bypass the VPN specifically so those connections keep working, while everything else remains protected.
App-based versus IP-based configuration
App-based split tunneling lets you designate specific applications to either always use the VPN tunnel or always bypass it, which is intuitive for cases like “keep my browser on the VPN but let my banking app connect directly.” IP-based, or destination-based, split tunneling instead routes traffic based on the destination address or network range, useful for excluding an entire local network segment or a specific set of known services regardless of which app is generating that traffic. Which configuration style is available, and how granular it is, varies significantly between VPN providers and operating systems.
The security tradeoffs involved
Any traffic excluded from the VPN tunnel loses every protection the VPN otherwise provides for that specific traffic: your real IP address is visible to that destination, your internet provider can see that specific connection’s content and metadata, and none of the encryption benefits apply to it. This is a deliberate, reasonable tradeoff for low-sensitivity traffic like reaching a local printer, but it becomes a meaningful risk if applied carelessly to genuinely sensitive traffic, since a misconfigured exclusion rule can silently route more than intended outside the tunnel’s protection without any obvious warning that it happened.
Government guidance on remote access architecture reflects this same tradeoff at an institutional level. NIST’s Guide to Enterprise Telework, Remote Access, and BYOD Security notes that tunneling solutions protect communications between the client device and the remote access gateway specifically, meaning any traffic deliberately routed outside that tunnel, as split tunneling does by design, falls back to whatever protections exist on the local network or destination alone.
When split tunneling makes practical sense
Split tunneling is a reasonable choice when you regularly need to reach local network devices while connected to a VPN, when specific applications perform poorly or break entirely when routed through a VPN and do not carry sensitive data, or when you want to preserve full local network speed for bandwidth-heavy local tasks while still protecting your general browsing traffic. It is a poor choice as a default, blanket configuration, since the whole point of running a VPN is undermined if too much traffic ends up excluded from it, whether intentionally or through an overlooked rule.
A concrete example worth walking through
Consider someone working from home who needs to both access a company’s internal systems over a VPN and print a document to a local network printer. Under a full tunnel, the printer often becomes unreachable because the device now appears to be on the company’s remote network rather than the home network the printer sits on. Configuring the printer’s IP address, or the printing application itself, to bypass the tunnel through split tunneling resolves this specific friction while leaving the actual sensitive work traffic still protected by the VPN exactly as intended. For more detail, see the IETF (RFC 4301), which covers the IPsec tunnel mode standard describing how tunneled traffic is protected versus traffic routed outside it.
