What split tunneling is (and isn’t)

Split tunneling is a networking approach where only part of your traffic goes through a VPN tunnel, while the rest uses your normal internet path. In practice, you define rules that decide which destinations are “VPN-bound” and which stay “local.”

This differs from full tunneling, where essentially all traffic is routed through the VPN. Split tunneling is often used to reduce latency for local resources, keep access to local networks, or avoid sending everything through the tunnel.

A key point for “secure and effective” is that split tunneling increases the importance of correctness: the VPN no longer covers everything by default, so mistakes in routing or name resolution can expose traffic that you intended to keep inside the tunnel.

How it works at a practical level

Most split-tunneling setups boil down to two mechanisms:

  1. Route selection (destination-based rules) Your device (or VPN client) decides for each connection which path to use based on the destination (for example, certain IP ranges, domains, or ports). If a destination matches a “VPN” rule, the connection is tunneled; otherwise it stays local.

  2. Name resolution (DNS) behavior Even when the final traffic destination is chosen correctly, DNS resolution can still reveal or redirect behavior. If DNS queries for “VPN destinations” resolve through the local network instead of the VPN-appropriate path, you can get privacy or security weaknesses.

Because DNS is often fast and automated, the safest approach is to align DNS resolution with the same intent as your routing rules: names that map to VPN-bound destinations should be resolved in a way that doesn’t bypass the protection model you’re aiming for.

How to set it up securely: a checklist-driven approach

Follow this order to reduce misconfiguration risk.

1) Decide the goal and the protected set

Before touching settings, write down which traffic you want to protect (for example, certain corporate subnets, specific SaaS endpoints, or only traffic to countries/regions you consider higher risk) and which you want to keep local.

If you cannot clearly define the protected set, split tunneling usually becomes trial-and-error—exactly the kind of setup where leaks are most likely.

2) Create clear “VPN-bound” routing rules

Use the most specific matching you can. Prefer:

  • Destination-based rules that clearly limit what enters the tunnel
  • Stable identifiers (such as well-defined IP ranges) when available

Be cautious with overly broad rules (e.g., “everything except local”), because they can accidentally route more traffic than intended or make it harder to reason about what is protected.

3) Align DNS with your routing intent

Common secure patterns include:

  • Ensuring DNS queries for VPN-bound names are handled in the intended path
  • Avoiding situations where local DNS resolution is used for destinations you expect to be tunneled

If your setup supports separate DNS settings for tunneled vs non-tunneled traffic, use them. If it doesn’t, you may need compensating controls (for example, firewall rules) to reduce the chance of DNS bypass.

4) Verify for “leaks,” not just for connectivity

Split tunneling can work and still be unsafe. Connectivity tests only confirm that apps load; they don’t always confirm the path used.

Instead, validate:

  • Whether VPN-bound destinations actually traverse the VPN path
  • Whether non-VPN destinations truly stay local
  • Whether DNS queries for VPN destinations avoid local resolution paths

5) Add firewall or policy safeguards where feasible

Even with VPN routing rules, OS firewalls can help enforce outcomes (for example, preventing direct egress to VPN destinations outside the intended path). This is especially relevant on networks where captive portals, local proxies, or unusual routing behavior might interfere.

Differences, exceptions, and limitations to expect

Split tunneling is not “set and forget.” Key limitations include:

  • Network changes can change behavior. Switching Wi‑Fi networks, moving between subnets, or joining managed networks can alter routes and DNS handling.
  • Apps may use unexpected connection patterns. Some applications open multiple connections, use proxies, or resolve and connect in ways that don’t exactly match your assumptions.
  • Domain-to-IP dynamics are real. If your rules depend on domain names, DNS answers can vary over time (CDNs, load balancing), which can complicate whether a connection matches a VPN rule.
  • IPv6 can bypass intended controls if you don’t cover it. If you only validate IPv4 behavior, IPv6 traffic may follow a different path.
  • “Local access” can still be risky. Traffic you intentionally keep local can expose you to local-network threats or metadata leakage; split tunneling doesn’t eliminate risks, it reallocates them.

A practical way to frame this: split tunneling can be secure when you can reason about and verify the protected vs unprotected paths under realistic conditions.

Practical checks you can run after setup

Use checks that confirm actual routing and resolution outcomes.

1) Confirm your apparent egress IP per destination

For a VPN-bound site and a local (non-tunneled) site, compare the externally observed IP (or other network-identifying signals) from the perspective of each destination. If both look the same, your “local vs VPN” separation may not be working.

2) Validate DNS path behavior

Check which DNS resolver is being used while reaching:

  • a VPN-bound hostname
  • a non-VPN hostname

If VPN-intended names are resolved through the local resolver, that can indicate a configuration mismatch.

3) Test IPv4 and IPv6 explicitly

Repeat your checks for both protocols. If one protocol is tunneled and the other is not, you may have unintended exposure.

4) Re-test after switching networks

Do a quick verification after joining a different Wi‑Fi network or switching from mobile data to Wi‑Fi. Split tunneling rules can be sensitive to route updates.

5) Use app-by-app validation for critical apps

If only certain apps matter (for example, browsers, email clients, or specific enterprise tools), validate each one. Some apps cache DNS, use different sockets, or retry through different mechanisms.

Summary: what “secure and effective” means here

To set up split tunneling securely and effectively, focus on three things: correct routing rules, aligned DNS handling, and verification that traffic takes the paths you intended. Expect limitations around app behavior, dynamic DNS, and network changes, and plan to re-check after environmental changes.

If you can define the protected traffic precisely and validate both connectivity and path behavior, split tunneling can be a controlled way to balance performance and protection—without assuming it covers everything.