VPN Split Tunneling: What It Is and When to Use It

VPN split tunneling is a configuration that sends only selected traffic through the VPN tunnel while the rest goes directly out the device's normal internet connection. Instead of forcing every packet through the corporate gateway (a 'full tunnel'), you decide which traffic is worth encrypting and backhauling, and let the rest take the short path.

It is one of the most common performance versus control trade-offs in enterprise networking, and getting it wrong in either direction has real consequences — so it is worth understanding exactly what it does.

How split tunneling works

At a technical level, split tunneling is a routing decision made on the client. The VPN client installs routes for the destinations that should use the tunnel; everything else follows the device's default route to the local gateway. So a laptop can reach an internal application over the VPN and stream a video call directly, at the same time.

Full tunnel does the opposite: the client installs a default route pointing into the tunnel, so all traffic — corporate or not — is encrypted and sent to the gateway, which inspects, logs and then forwards it. That gives the security team complete visibility at the cost of latency and gateway capacity.

The three types of split tunneling

There are three common variants, and vendors name them differently. Route-based (or split-include) tunneling sends specific destination networks through the VPN. Inverse (or split-exclude) tunneling sends everything through the VPN except named destinations. Application-based split tunneling decides per app — this app's traffic uses the tunnel, that one does not.

• Route-based: tunnel only defined subnets, e.g. the corporate 10.0.0.0/8. Simple and predictable.
• Inverse / exclude: tunnel everything except, say, Microsoft 365 or a video service, to spare the gateway.
• Application-based: route by process — useful on managed endpoints where you trust the app list.

The security trade-off

Split tunneling improves performance and reduces gateway load, but it narrows what the security team can see. Traffic that bypasses the tunnel is not inspected, not filtered by the corporate proxy, and not logged centrally. If a device is compromised, the direct path is exactly where an attacker would prefer to operate.

Full tunnel preserves visibility and lets you apply one consistent set of egress controls, which is why regulated environments often mandate it. The modern middle ground is to pair a tight split-tunnel policy with endpoint protection and DNS filtering on the device itself, so the bypassed traffic is not entirely unguarded.

This is also one of the arguments people make for moving beyond VPNs altogether: a zero trust model checks each request regardless of the network path, which sidesteps the split-versus-full debate for application access.

When to use it

Use split tunneling when gateway bandwidth or user latency is the constraint and the bypassed traffic is low-risk — cloud productivity suites and real-time media are the usual candidates. Use full tunnel when you need complete egress visibility, when compliance requires it, or when endpoints are not fully trusted.

Whichever you choose, it is a policy decision that belongs in your wider remote-access design. For how the remote-access tunnel itself works, see remote-access VPN explained, and for where split tunneling sits among the other choices, the business VPN guide has the overview.

Why cloud apps drive the decision

The single biggest reason split tunneling became mainstream is cloud SaaS. When most corporate traffic went to a data centre, full tunnel was natural. Now that a large share of a workday is Microsoft 365, Google Workspace, Zoom or Teams — services delivered from vast content-delivery networks close to the user — backhauling all of it to a central gateway and back out again adds latency, wastes gateway bandwidth and can degrade real-time media.

This is why vendors and cloud providers publish recommended exclude lists: send those high-volume, low-risk SaaS endpoints directly, and tunnel only the traffic bound for internal systems. It is an inverse (exclude) split-tunnel policy, and it is the pragmatic default for a lot of hybrid workforces. The catch is that the exclude list must be maintained as providers change their address ranges, or the policy silently stops matching.

Configuring split tunneling safely

If you deploy split tunneling, tighten it deliberately rather than leaving it wide open. A few practices keep the trade-off in check.

• Keep the tunnel list narrow and explicit. Prefer split-include (tunnel only named corporate subnets) where you can, so anything internal you forget defaults to being protected, not exposed.
• Guard DNS. Split tunneling that leaks internal DNS queries to a local resolver can break name resolution or expose internal hostnames; use split-DNS so corporate domains resolve through the tunnel.
• Keep endpoint controls on the direct path. Endpoint protection, DNS filtering and disk encryption matter more when traffic bypasses the corporate proxy, because they are the only controls left on that path.
• Review the exclude list on a schedule. Treat provider IP ranges as data that drifts, and re-check them rather than setting and forgetting.

Done this way, split tunneling is a reasonable engineering compromise. Done carelessly — a broad exclude, no DNS handling, unmanaged endpoints — it quietly removes most of the value of having a VPN at all.

The bottom line

Split tunneling is neither good nor bad in itself; it is a deliberate trade of visibility for performance, and the right setting depends on your risk tolerance and how much you trust the endpoint. Performance-driven teams with well-managed devices lean toward a tight, well-maintained split policy. Regulated or high-assurance environments lean toward full tunnel, accepting the latency and gateway cost in exchange for complete egress control.

If you find yourself fighting the trade-off constantly — wanting the performance of split tunneling but the control of full tunnel — that tension is one of the clearest signals that per-application access under a zero trust model may suit you better than tuning tunnel routes forever. Either way, decide it explicitly and document why, because an undocumented split-tunnel policy tends to drift wider over time until nobody remembers what is and is not protected.