Split tunneling routes some traffic through a VPN and some through the ordinary connection. It can preserve local printer access, reduce bandwidth use and keep latency-sensitive services direct.
The security trade-off
Traffic outside the tunnel uses the local network and public IP. On a corporate device, an untrusted local path may also become a bridge between internet services and protected resources if controls are weak.
Choose explicit rules
Document which applications or destinations bypass the VPN and why. Test DNS alongside application traffic; inconsistent routing can reveal destinations or break internal names.
When to avoid it
Privileged administration, sensitive remote work and high-risk travel may justify full tunneling. Follow the organization's policy rather than enabling split routing for convenience.
Split tunneling is not inherently wrong. It is a routing decision that should have a named owner, a measurable benefit and a test showing which traffic goes where.
Domain rules can be unstable
Large services change addresses and use shared infrastructure, so a domain-based exception may route more or less traffic than expected. Application-based rules are easier to explain but still need update testing.
Logging and support
Record the intended route in support documentation. When a user reports that an internal service works only sometimes, split DNS and split tunnel policy should be checked together rather than troubleshooting the application alone.
Classify traffic by sensitivity and dependency
Internal administration, credentials and confidential data usually belong inside the tunnel. Video calls or local printers may be reasonable exceptions when policy allows. Record why each application is excluded and which network it will use; convenience alone is not a risk assessment.
Expect interactions with DNS and identity
An internal service may resolve only through corporate DNS while its application is mistakenly routed outside. A public service may see two addresses during one session and trigger fraud controls. Test updates, authentication, IPv6 and reconnect behavior after every policy change.
For regulated work, central configuration and logs are preferable to user-selected exceptions. The objective is predictable routing, not the largest possible bypass list.
Classify data before creating exceptions
Split tunneling sends selected applications or destinations outside the VPN. It may improve video performance or let a user reach a local printer, but it also places excluded traffic on the ordinary network. Classify the information and authentication involved before choosing the convenient route.
Avoid split routing for administrative systems, confidential work and environments where policy depends on the corporate gateway. The exception list should have an owner, reason and review date rather than grow whenever an application is slow.
Expect DNS and identity interactions
Internal applications may require corporate DNS, source addresses or identity signals available only through the tunnel. Domain-based rules can be unstable because large services change addresses and use shared infrastructure. Application rules are easier to explain but still need update testing.
Verify the route with public IP, DNS and application logs. Test after sleep, network changes and client updates. Support documentation should state which traffic is expected inside and outside the tunnel so intermittent access is diagnosed against the intended design.