How VPN split tunneling works

VPN split tunneling lets you choose which network traffic goes through the encrypted VPN tunnel and which traffic goes out directly to the internet. Typically, a VPN client or configuration defines a set of “included” destinations (for example, certain internal IP ranges or domains) that should use the VPN, while everything else follows the normal local route.

Because only part of your traffic is tunneled, your connection behavior can differ depending on the destination:

  • Requests to included private networks or domains traverse the VPN and rely on the VPN’s routing and DNS.
  • Requests to everything else bypass the tunnel and use your local network path.

This division is the source of both the benefit and the risk: you get more control and potential performance gains, but you also create more opportunities for mismatched routing, name resolution, and firewall expectations.

Common problems and what usually causes them

1) Private services don’t load over the VPN

A frequent symptom is that “internal” web apps, admin portals, or other private endpoints fail when split tunneling is enabled.

Common causes include:

  • The included routes (CIDR ranges or host rules) don’t actually cover the destination you’re trying to reach.
  • The destination uses a different hostname or resolves to IPs that are not included by your tunneling rules.
  • Local routing takes precedence for that destination before the VPN can direct it.

What to look for: whether the failure is destination-specific. If public websites work but only internal ones fail, split tunneling rules or name resolution boundaries are likely.

2) DNS mismatches (hostnames resolve differently)

Split tunneling often depends on DNS behavior. If your device resolves a private hostname to an IP address that is not reachable through the VPN path—or is reachable only via VPN DNS—you can get confusing partial failures.

Typical patterns:

  • The VPN should provide name resolution for internal domains, but your system is still using the local DNS server for those names.
  • A hostname resolves to an IP that changes (for example, via multiple records) and only some of those IPs are covered by the split tunneling rules.

3) “It works sometimes” due to caching and dynamic addressing

Even when routing rules are correct, results can vary because of DNS caching, changing IPs, or application-level retry logic.

If you notice intermittent failures:

  • DNS caches (OS or browser) may keep old answers that map to IPs outside the included ranges.
  • The private service may use multiple backends with different network paths.

4) Firewall or security policy conflicts

Split tunneling may also trigger local firewall or endpoint security rules, because traffic arrives from different local interfaces depending on whether it traveled over the VPN tunnel or the direct internet path.

This can cause:

  • Blocked connections to VPN-routed destinations.
  • Unexpected prompts or denied traffic for specific apps.

5) Performance expectations don’t match reality

Split tunneling is often chosen to avoid routing everything through the VPN, but bottlenecks can still appear. If a “large” portion of your traffic ends up tunneled due to broad inclusion rules, performance may degrade.

The key limitation: split tunneling doesn’t automatically optimize performance; it just changes the path by rule.

Differences and limits to be aware of

Split tunneling vs full tunneling

Full tunneling sends essentially all traffic through the VPN, reducing ambiguity because there’s a single routing and DNS path. Split tunneling increases flexibility but also increases the need to ensure that every “internal” dependency you rely on is included correctly.

Practical limit: if your application needs both internal and external resources (often with callbacks, APIs, or embedded resources), those sub-requests may land on different paths. That can still work, but it makes debugging harder.

“Included” rules usually depend on IPs and name resolution

Even if you configure split tunneling for domains, the actual network path is determined by how those names resolve and which IPs you include. If the resolved IPs don’t match the included ranges, traffic may bypass the VPN and fail.

Some protocols may behave unexpectedly

Protocols that rely on dynamic connections—like certain peer-to-peer behaviors, multi-connection workflows, or services that return redirects—can produce traffic to destinations you didn’t explicitly anticipate. If those follow-up destinations are not included, the workflow breaks.

Practical checks you can run

1) Verify which path traffic is using

Use basic observations to confirm behavior:

  • Test a known private endpoint and note whether it fails only under split tunneling.
  • Compare the same action in a session where VPN is configured for full tunneling (if available) to isolate whether the problem is split-specific.

Goal: confirm whether your issue is limited to the set of tunneled destinations.

2) Validate DNS for internal names

Check whether internal domain names resolve to addresses you expect, and whether those addresses are within your included ranges.

Practical approach:

  • Resolve the internal hostname and compare the resulting IP(s) to the CIDR or host rules used by split tunneling.
  • After changing DNS-related settings, clear relevant caches (OS/browser) and re-test, especially if you see intermittent behavior.

3) Check route coverage with real destination IPs

For IP-based rules, confirm you used the correct network ranges. For hostname-based rules, confirm the hostname resolves to included IPs at the time of testing.

If you’re unsure, use multiple trials against different endpoints within the same service to reveal missing coverage.

4) Review local firewall and application rules

Confirm that security software is not blocking traffic differently depending on the interface used by the VPN tunnel.

What to look for:

  • Denied logs or prompts for the tunneled app during the failure moment.
  • Differences between how the app behaves when traffic is routed through the VPN vs bypassing it.

5) Reduce variables by changing one setting at a time

When debugging, keep scope tight:

  • Make one change (DNS settings, included ranges, or firewall rule) and retest.
  • Note the specific endpoint that breaks and the specific step of the workflow.

This turns an ambiguous problem (“VPN split tunneling is broken”) into a measurable one (“DNS for X resolves outside included ranges”).

When to avoid split tunneling

Split tunneling may be the wrong tool when:

  • You cannot reliably maintain correct routing and DNS inclusion for all required private dependencies.
  • Your workflows depend on many dynamic destinations that are hard to predict.
  • Debugging time matters more than potential performance gains.

In those cases, moving to a more consistent routing model (for example, routing more or all traffic through the VPN) can reduce ambiguity, even if it changes performance characteristics.