Split tunneling is one of those VPN features that sounds immediately useful until you trace exactly what it does to your traffic. It allows users to route some connections through the encrypted VPN tunnel while letting others travel directly to the internet — but that division creates an attack surface that most VPN marketing materials gloss over entirely.
How Split Tunneling Actually Works
A standard VPN configuration captures all outbound traffic at the network adapter level and forces it through an encrypted tunnel to a remote server. Split tunneling breaks that model by applying routing rules that sort traffic before it leaves the device. Those rules can be based on application, destination IP range, or domain name, depending on the VPN client and protocol in use.
There are two common configurations. In “include” or app-based split tunneling, you specify which applications or addresses go through the VPN — everything else goes direct. In “exclude” split tunneling (sometimes called inverse split tunneling), all traffic goes through the VPN except the destinations you explicitly exclude. The distinction matters because the default behavior differs, and misconfiguring one for the other can leave sensitive traffic completely unprotected without any obvious indication.
At the protocol level, VPN clients implementing split tunneling modify the device’s routing table during an active session. OpenVPN, for instance, can accept pushed routes from the server or accept client-side route configurations that override the default gateway only for specified subnets. WireGuard handles this through the AllowedIPs directive — setting AllowedIPs = 0.0.0.0/0 routes everything through the tunnel, while listing specific CIDR blocks restricts tunneling to only those ranges. This means split tunneling in WireGuard is fundamentally a routing table decision, not a separate feature.
DNS behavior during split tunneling is where many implementations quietly fail. If the VPN client doesn’t also split DNS resolution — routing queries for tunneled destinations to the VPN’s DNS server and direct-traffic queries to the local resolver — DNS leaks become likely. A user might route their corporate application traffic through the VPN while every DNS query for those same applications goes to their ISP’s resolver, exposing connection metadata even if the payload is encrypted.
Legitimate Use Cases and Why They Make Sense
The most defensible use of split tunneling is bandwidth management on corporate networks. When a remote employee routes all traffic through a company VPN, every video call, cloud storage sync, and browser request passes through the corporate gateway. This creates latency, saturates the VPN concentrator, and adds cost. Routing only internal resource access through the VPN — file servers, internal web applications, Active Directory authentication — while letting general internet traffic go direct is a reasonable operational decision when those internal resources are the actual threat surface being protected.
Gaming and real-time media are another category where split tunneling serves a clear function. VPN encryption and the additional network hop both add latency. A user who wants their torrent client or streaming service to bypass the VPN while keeping their browser traffic private is making a tradeoff that may be entirely appropriate for their threat model. The key phrase is “their threat model” — this is a personal use case, not an enterprise security policy.
Some organizations use split tunneling specifically to allow cloud SaaS traffic to reach providers directly rather than hairpinning through an on-premises VPN gateway. Microsoft’s published guidance for Office 365 deployment explicitly recommends that Teams, SharePoint Online, and Exchange Online traffic should bypass VPN tunnels and connect directly to Microsoft’s endpoints, citing the latency and reliability improvements this produces. This is documented in Microsoft’s Office 365 network connectivity principles and reflects a real architectural pattern, not a workaround.
The scenario where split tunneling is unambiguously appropriate is when the tunneled destination is inherently trusted and the bypassed traffic is low-sensitivity. A developer tunneling only traffic destined for their company’s internal subnet while their personal browsing goes direct has separated concerns cleanly — assuming the implementation is correct and DNS is handled properly.
Split tunneling also appears in the context of accessing geo-restricted content. A user might route traffic to one country’s streaming platform through a VPN endpoint in that region while keeping all other traffic local. This works, but it only addresses the specific privacy concern of hiding location from that one service — it does nothing to protect the rest of the browsing session.
Where Split Tunneling Breaks Security
The most significant risk is that split tunneling creates a device with simultaneous access to a protected network and the open internet. On a properly configured full-tunnel VPN, the device only communicates with external networks through the VPN gateway, which can apply filtering, logging, and access controls. With split tunneling active, a piece of malware on the device can use the direct internet path to communicate with a command-and-control server while the device maintains its trusted VPN session. The corporate network effectively has no visibility into that activity.
This becomes a serious problem in endpoint-compromise scenarios. If an attacker gains code execution on a remote employee’s machine, split tunneling means they inherit both the open internet connection and the VPN tunnel to internal resources. A full-tunnel configuration at least forces all traffic through a choke point where network monitoring tools have a chance to detect anomalous behavior.
Endpoint isolation is the other failure mode. Many zero-trust architectures assume that traffic from a VPN-connected device has passed through some form of inspection. Split tunneling undermines that assumption by letting arbitrary traffic leave the device without inspection. Network Detection and Response (NDR) tools that monitor traffic at the VPN gateway see only the tunneled portion — the direct traffic is invisible to them entirely.
There are also endpoint-specific routing vulnerabilities worth naming. On macOS and Windows, the routing table modifications made by VPN clients for split tunneling can be manipulated by applications with sufficient privileges. A malicious application or a confused routing state after a VPN reconnection can result in traffic that was supposed to be tunneled traveling in the clear instead, without the user or the VPN client detecting the change. This class of bug has appeared in multiple commercial VPN clients over the years, including documented issues in older versions of PulseSecure and Cisco AnyConnect.
App-based split tunneling introduces a trust assumption about application identity. Routing decisions based on process name — “send Firefox traffic through the VPN, send Chrome traffic direct” — assume that process names are meaningful security boundaries. On Windows, application-based routing in some implementations can be bypassed by renaming an executable to match a tunneled application’s process name, because the enforcement happens at the process label level rather than through cryptographic verification of the binary.
Practical Guidance Before Enabling Split Tunneling
Before enabling split tunneling, it’s worth mapping exactly which traffic you’re excluding and verifying that DNS resolution follows the same rules as your data plane routing. A split tunnel with unified DNS is a different security posture than one leaking every hostname lookup to a local resolver.
The question that determines whether split tunneling is appropriate isn’t whether it’s convenient — it’s whether a compromise of the device’s non-tunneled traffic path could reach the tunneled network. If those two environments are completely air-gapped in terms of what a local process could access from one to the other, split tunneling’s risks are bounded. If a process on the device can freely read from both paths, the split is largely a fiction. WireGuard’s AllowedIPs configuration makes this boundary explicit and auditable, which is one reason it’s worth examining in raw config rather than relying on a GUI to summarize it accurately.
