Split tunneling: what it is and how it works

Split tunneling in plain terms

Split tunneling is a VPN configuration that sends only some network traffic through the VPN tunnel, while the rest of the traffic bypasses the tunnel and goes out through your normal internet connection.

Think of it as “selective routing.” For example, a device can send work-related services (such as access to a corporate website) through the VPN while allowing other activities (such as general web browsing, streaming, or local network access) to use the direct path.

How split tunneling works under the hood

In practice, split tunneling is implemented by rules that decide which traffic should be tunneled and which should not. Those rules typically operate on one or more of the following dimensions:

Destination-based routing: traffic to certain IP ranges or domains is sent into the VPN tunnel.
App/process-based routing: traffic generated by specific apps or processes is tunneled, while other apps use the direct route.
Route and policy decisions: the system’s networking stack applies policy so that matching traffic is directed to the VPN interface.

When your device sends traffic, it evaluates these rules. If the traffic matches a “tunnel” rule, it is encrypted and sent through the VPN. If it doesn’t match, it is not carried inside the tunnel and instead leaves via your usual network path.

Because the decision happens per connection/flow, split tunneling can lead to a mix of paths at the same time: some connections appear to come from the VPN endpoint, while other connections appear to come from your local network.

Why people use it (and what changes)

The main motivations are usually practical:

Performance and latency: bypassing the VPN for some traffic can reduce overhead and make certain services feel faster.
Compatibility: some applications may work better on the direct path, especially those that need local network characteristics.
Local access: you might want access to printers, NAS devices, or other local resources without sending those requests through the VPN.

However, split tunneling changes your threat model. Traffic that is excluded from the tunnel is not protected by the VPN in the same way, because it does not travel through the encrypted tunnel. Exactly what that means depends on what you exclude and what risks you’re trying to address.

Differences and limits to watch

Split tunneling is not “all-or-nothing.” A common limitation is that the overall security/privacy outcome depends on how the exclusion rules are defined.

Key limits and gotchas include:

What you bypass becomes your responsibility: if you exclude sensitive destinations or apps, those connections follow the normal path and are exposed to whatever security properties your local network and connection provide.
DNS behavior matters: if name resolution (DNS) is not handled consistently with the tunneled traffic, you can see unexpected leaks or mismatches between “what you intend to tunnel” and “what actually gets routed.” (Details vary by setup.)
Inconsistent identity signals: with mixed routing, different services may observe different IP addresses or geolocation signals, which can affect access control or logging on the services you use.
Routing complexity increases configuration risk: more selective rules mean more room for mistakes, such as unintentionally tunneling too much (hurting performance) or excluding too much (reducing protection).

Also note: terms can overlap in everyday conversation. Some people use “split tunneling” loosely, while others distinguish related concepts (like split-DNS) as separate configuration choices. Treat the behavior you observe—where connections actually go—as the ground truth, not the label.

Practical checks you can do

You can verify split tunneling behavior with non-destructive, observable tests:

Compare apparent egress for different destinations Use a “what is my IP” style check on the client (for example, via separate browser sessions) while accessing both tunneled and non-tunneled destinations. If split tunneling is working, you should see some destinations appear to use the VPN egress and others appear to use your local egress.
Inspect active connections and routing at the device level Use OS network tools to look at active connections and which network interface they use. You’re looking for whether certain connections go via the VPN interface and others do not.
Test local network access scenarios If the goal of split tunneling is local resource access, try reaching a local service (like a NAS or printer) while confirming whether those connections remain direct. If they accidentally go through the tunnel, discovery and reachability often behave differently.
Confirm DNS consistency for the paths you care about When you use domain-based routing rules, verify that DNS resolution aligns with your intended routing. Inconsistencies can lead to requests reaching destinations you didn’t expect.

Red flags (behavior that suggests a mistake)

Services you expected to be protected show the local network egress.
Local resources fail to work even though you intended bypass.
You see inconsistent VPN-provided identity signals across sites that should behave similarly.

If you encounter these issues, revisit the rule logic (app-based vs destination-based), the DNS setup, and whether the client is applying the routing rules to the traffic you care about.

Two common adjacent ideas are:

Full tunneling: all traffic is sent through the VPN tunnel. This is simpler but may add overhead.
Split-DNS: DNS resolution is configured so that some queries use VPN-related resolution while others do not. This can be independent from whether the actual traffic is tunneled.

When troubleshooting split tunneling, it helps to consider that DNS and traffic routing can be configured separately, even if the UI presents them together.

Uncertainty to keep in mind

Exact rule types, naming, and supported features vary by VPN client and operating system. The reliable approach is to test and observe: confirm which connections use the tunnel and which do not, then align your security expectations with that observed behavior.