Split tunneling, explained plainly

Split tunneling is a VPN configuration where not all network traffic is forced through the VPN tunnel. Instead, the VPN client routes only certain traffic—typically defined by destination IP ranges, domain rules, or application selection—through the encrypted tunnel. All other traffic follows your usual local network route (for example, directly to the internet via your ISP).

From a practical perspective, split tunneling is a traffic-management choice. It can reduce latency for non-sensitive traffic and avoid sending every request through the VPN. At the same time, it increases the importance of getting the routing rules right, because anything you fail to include in (or exclude from) the split rules may go over the non-VPN path.

How it works at a routing level

Most operating systems and VPN clients implement split tunneling using routing and policy decisions. Conceptually, the workflow looks like this:

  1. VPN creates an encrypted tunnel interface on your device.
  2. Routing rules decide where packets go when an application tries to connect.
  3. For “selected” destinations, packets are directed to the VPN interface and sent through the tunnel.
  4. For “not selected” destinations, packets are routed normally without entering the tunnel.

Depending on the platform and client, the “selected” set can be expressed as:

  • Destination-based rules (e.g., certain IP ranges)
  • Domain-based rules (often mapped to IPs via DNS)
  • Application-based rules (some OSes allow selecting by process)

Because routing decisions occur at the network layer (or close to it), split tunneling is best understood as policy-based routing rather than a security feature by itself. The security outcome depends on what traffic matches your rules.

Correct setup: what to configure

A “correct” split-tunneling setup usually means the VPN client is configured so that the destinations you intend to protect are routed into the tunnel, while unrelated destinations remain on the local path.

When setting up split tunneling, focus on these rule-design questions:

  • What exactly should be protected? If your goal is privacy or security for specific services, base your selections on those services’ endpoints (domains/IP ranges) or the apps that use them.
  • What should stay local? Non-sensitive browsing or background updates are common candidates, but confirm they do not include traffic you assumed was protected.
  • How are rules interpreted? Some setups use allowlists (only selected traffic goes through the VPN), while others use deny lists or exclusions. The safest approach is to align your rules with your actual intent (protect what matters; leave everything else unselected).

DNS behavior matters

Even if you set destination rules, DNS can change the outcome. Many domain-based rule systems rely on DNS resolution to determine where connections go. If DNS queries or DNS responses take a different path than you expect, you can see surprising routing behavior.

A general way to think about this: if your VPN rules are domain-oriented, you want name resolution for those domains to be consistent with the routing policy you intended.

Differences and limits (and why setups vary)

Split tunneling is not a single universal mechanism; it depends on the OS routing stack and the VPN client’s capabilities. Common limitations and edge cases include:

  1. Coverage gaps from incomplete rules If you only include some IP ranges or only some domains, other endpoints for the same service may not match and can bypass the VPN tunnel.

  2. Dynamic or changing destinations Services that use CDNs, geo-routing, or frequently changing IPs may make destination-based allowlists hard to keep accurate.

  3. Application behavior and ports Some apps open multiple connections (including to “helper” services). If your application-based split selection is imperfect, only part of the traffic may be tunneled.

  4. DNS mismatches If DNS traffic doesn’t follow the same policy you assume, connections may be routed based on resolutions that don’t correspond to your intended tunnel selection.

  5. Firewall and OS constraints Local firewall rules, VPN client restrictions, or OS permissions can affect whether routing decisions apply as expected.

The main security takeaway

Split tunneling can be reasonable, but its security value depends on correctness of the selection rules. Misclassification is the typical failure mode: traffic you expected to be protected may take the non-VPN path.

Practical checks you can do

Because split tunneling outcomes are configuration-specific, it helps to verify behavior rather than assume it is correct.

Use these practical, non-destructive checks:

  1. Test known “should be tunneled” destinations Visit or connect to a service you expect to be routed through the VPN, and confirm that the apparent network identity (such as observed egress IP) changes accordingly. If egress remains the same as when you are not using the VPN, your tunnel selection may not be matching.

  2. Test known “should stay local” destinations Connect to something you intend to exclude from tunneling, and confirm that it behaves differently from the tunneled test. If both behave identically, your split rules may not be applying.

  3. Verify DNS expectations for domain-based rules If your rules are domain-oriented, compare how DNS resolution behaves when split tunneling is enabled versus disabled. If name resolution clearly differs, it may explain mismatches in routing.

  4. Check that multiple endpoints are covered For services with multiple subdomains or regional endpoints, test a few variations. If some subdomains bypass the tunnel, refine your rules.

  5. Observe application traffic patterns If only part of an application’s traffic appears tunneled, assume it may be contacting different domains/IP ranges than you captured. Adjust the rule basis accordingly.

Split tunneling often overlaps with related ideas:

  • Allowlists vs deny lists: An allowlist approach routes only explicitly listed destinations through the VPN. A deny list approach routes most traffic through the VPN except excluded destinations. Which one is safer depends on your intent.
  • Policy routing: Under the hood, the decision is essentially a routing policy—based on destination, application, or other match criteria.
  • Route-based vs interface-based selection: Some clients steer traffic by routing table entries, while others use higher-level selection and then translate it to routes. The visible effect should be the same: selected traffic enters the tunnel.

If you keep one mental model, use this: split tunneling is about who matches the rule set. The “correct setup” is the one where the match set equals your real definition of sensitive versus non-sensitive traffic.

If something looks wrong

If your tests suggest traffic is bypassing the VPN tunnel when it shouldn’t, common next steps are:

  • Re-check whether the destination/domain you tested actually matches the rule criteria. - Confirm DNS behavior aligns with your domain-based matching approach.