VPN split tunneling sends only selected traffic, such as company network ranges, through the VPN tunnel, while all other traffic goes directly to the internet. It reduces load and speeds up cloud apps. The trade is that the direct traffic skips your inspection, and the device can bridge the two paths.
How does it work?
In IPsec, which NIST SP 800-77 Rev. 1 describes, the tunnel carries the traffic that matches defined traffic selectors. IKEv2, specified in RFC 7296, negotiates those selectors. If the selector is everything, you have full tunneling. If it is only internal address ranges, you have split tunneling, because traffic to other destinations never enters the tunnel.
The alternative is full tunneling, where all device traffic goes to the corporate side and then out through its egress controls.
What do you gain?
Split tunneling saves VPN capacity, because video calls and software updates do not cross the concentrator. It also usually gives users lower latency to cloud services.
What do you give up?
The main loss is visibility. Traffic that skips the tunnel skips the proxy, the DNS filter and the logging at your egress point. If a user's laptop visits a malicious site, your central tools do not see it.
A second risk is the device itself. With two active paths, a compromised machine on a hostile home or café network can act as a bridge into the tunnel. That is why endpoint health matters more under split tunneling.
A third risk is leakage by mistake. RFC 7359 describes how VPN tunnel traffic can leak out in the clear on dual-stack hosts when VPN software does not handle IPv6, so traffic meant for the tunnel goes out unprotected. Test for it.
A constructed example
A company allows split tunneling so that video meetings do not overload the VPN. Internal apps stay inside the tunnel. A user's laptop gets infected through a malicious download on the direct path, then connects to the internal file server over the tunnel. Because the download never crossed the company proxy, no alert fired. The fix is not necessarily to ban split tunneling. It is to run endpoint protection with central reporting on the device and to restrict what the VPN account can reach.
When is it acceptable?
It fits when most traffic goes to well-known SaaS services you already control through identity and device policy, when the endpoint has managed protection and logs, and when the internal side limits each user to the systems they need. NIST SP 800-207 on zero trust points the same way: access should rest on identity and device state per resource, not on the network path alone.
It fits poorly for devices that handle regulated data without endpoint controls, or for unmanaged personal devices.
What about DNS?
DNS is the part most often forgotten. If internal names resolve through the tunnel but other lookups go to a local resolver, you get a split view that is hard to debug and easy to exploit. Decide which names use which resolver, and watch for lookups of internal names leaking to public resolvers.
How to check or apply this
- Decide which traffic must stay in the tunnel: internal ranges, admin interfaces, and anything that needs central inspection.
- If you allow split tunneling, require managed devices with up-to-date protection and disk encryption.
- Route DNS for internal names through the tunnel and consider a protective DNS service on the endpoint for the rest.
- Send endpoint logs to central storage, since the network will not see direct traffic.
- Limit VPN accounts to the minimum set of internal systems.
- Test for IPv4 and IPv6 leakage from a client on a home network.
- Review the policy each time you add a major SaaS app or a regulated data set.
Quick check
Is full tunneling always safer?
It gives more central visibility, but it also costs bandwidth, and a compromised device is still a risk. Safer depends on the endpoint controls you pair it with.
Can split tunneling leak internal traffic?
It can if routes are misconfigured or IPv6 is not handled. Test from a real client.
Sources
- NIST SP 800-77 Rev. 1, Guide to IPsec VPNs
- RFC 7296, Internet Key Exchange Protocol Version 2
- RFC 7359, Layer 3 VPN Tunnel Traffic Leakages in Dual-Stack Hosts and Networks
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
