VPNSmith
tunneling-obfuscationINFO

What Is Split Tunneling? VPN Routing Explained (2026)

Split tunneling lets you choose which traffic goes through your VPN and which goes straight over your normal connection. How it works, the types, why people use it, the honest privacy trade-off, and how to do it on self-hosted WireGuard.

By Eric Gerard · Founder · VPNSmith - Self-host VPN & GDPR VPS specialist7 min readImage: Pixabay

By default, a VPN is all-or-nothing: switch it on and everything your device sends goes through the encrypted tunnel. Split tunneling breaks that rule. It lets you pick which traffic goes through the VPN and which takes your normal connection - useful, but with a catch worth understanding. This guide explains what split tunneling is, the types, why people use it, the honest trade-off, and how to do it on a self-hosted WireGuard setup.

The short definition

Split tunneling is a VPN feature that routes some of your traffic through the encrypted tunnel and lets the rest go directly over your normal internet connection. Instead of one tunnel carrying everything, you split your traffic into two paths: protected (through the VPN) and direct (not). You decide which is which.

How it works

You set rules that tell the VPN which traffic to include or exclude. Those rules usually work one of a few ways:

  • App-based - choose specific apps to send through the VPN (or to keep off it). Common on desktop and Android VPN clients.
  • Destination-based - route by IP range or domain, so traffic to certain sites or networks uses the tunnel and the rest doesn't.
  • Inverse split tunnel - everything goes through the VPN except a short list you exclude (handy for one app that misbehaves behind a VPN).

Whatever the method, the VPN client applies your rules to each connection and sends it down the right path.

Ethernet cables plugged into a numbered network switch - split tunneling decides which connections travel through the VPN and which go direct.
Ethernet cables plugged into a numbered network switch - split tunneling decides which connections travel through the VPN and which go direct.

Why people use it

Split tunneling is mostly about convenience and performance:

  • Speed and bandwidth. Traffic that doesn't need protecting skips the VPN's extra hop, so it's faster and doesn't eat the tunnel's throughput. Large downloads or video calls often go direct.
  • Local network access. You can reach your printer, NAS or other home devices while the VPN stays on for everything else - normally a full tunnel would cut you off from them.
  • Dual access. Use a service that blocks VPNs (some banking or streaming apps) over your real connection while another app stays on the VPN - no toggling on and off.

The honest trade-off

Here's the part that matters: anything you route outside the tunnel is not protected. That traffic uses your real IP and is visible to your network and ISP, exactly as if the VPN were off. Split tunneling trades some protection for convenience, and the main risk is misconfiguration - excluding something sensitive by accident, or a DNS query leaking outside the tunnel and revealing what you're doing.

So the rule of thumb is simple: only exclude traffic you genuinely don't mind being unprotected. If you're using a VPN for privacy or on a hostile network, a full tunnel - everything through the VPN - is the safer default, and split tunneling is the deliberate exception you make for a specific app.

What your operating system does by default

Most explanations of split tunneling skip the question that decides everything in practice: what happens if you configure nothing at all?

On Windows, Microsoft's documentation answers it directly. Force tunnel is the default configuration, and takes effect when no routes are specified. In a force tunnel configuration, all traffic goes over the VPN. Split tunneling is therefore not the state you fall into by accident, it is the state you have to ask for.

The mechanism is worth knowing because it demystifies the whole subject. Microsoft describes the only implication of force tunnel as the manipulation of routing entries: the VPN's IPv4 and IPv6 default routes, 0.0.0.0/0 and its v6 equivalent, are added to the routing table with a lower metric than ones for other interfaces. Traffic then goes through the VPN as long as there is no more specific route on the physical interface.

That is the same idea the WireGuard configurations below express with AllowedIPs. Different vendors, different syntax, one mechanism: whoever owns the most specific route owns the traffic.

Two practical points follow.

Split tunneling is a routing decision, not a security feature. Microsoft frames the choice as one that impacts the configuration, capacity planning, and security expectations from the connection. It changes which packets are protected, so it changes what the connection promises, and that is a decision to make deliberately rather than a setting to enable because it sounds faster.

Exclusion routes exist too. With Windows VPN you can specify routes that should not go over the tunnel, which is the mirror image of choosing what does. Both directions produce a split tunnel; they differ in whether your default is trust or exclusion.

Doing it yourself on WireGuard

If you run your own VPN, you already have split tunneling - it's just the AllowedIPs setting in your WireGuard client config. AllowedIPs = 0.0.0.0/0, ::/0 routes all traffic through the tunnel (a full tunnel). List only specific subnets instead, and only that traffic uses WireGuard while everything else stays on your normal connection (a split tunnel). No special toggle required - the routing config is the control, which is one more reason a self-hosted WireGuard server gives you precise command over your traffic.

Concrete WireGuard configs

Because AllowedIPs is the control, it helps to see the actual lines rather than the principle. These go in the [Peer] section of your client config.

Full tunnel - everything through the VPN, the safe default:

AllowedIPs = 0.0.0.0/0, ::/0

Split tunnel, remote subnet only - reach your home or office network through the VPN, everything else goes direct:

AllowedIPs = 10.0.0.0/24

Split tunnel, VPN network plus one service - the tunnel carries your private subnet and a specific destination:

AllowedIPs = 10.0.0.0/24, 203.0.113.10/32

A single address needs the /32 suffix (or /128 for IPv6). Note what this design implies: WireGuard splits by destination, not by application. If you need per-app rules, that logic lives in your VPN client or your operating system, not in WireGuard itself.

Check that it actually works

A split tunnel that silently routes more, or less, than you intended is the common failure. Two checks settle it.

Which route is used. On Linux or macOS, ip route get 1.1.1.1 (or route get 1.1.1.1) shows the interface a destination will use. If it names your WireGuard interface for something you meant to exclude, your AllowedIPs is broader than you think.

What the internet sees. Load an IP-checking page from inside the app you routed through the tunnel, and from an app you excluded. The first should show the VPN server's address, the second your real one. If both show the same address, you do not have a split tunnel, you have a full tunnel or none at all.

The DNS trap

This is the failure that catches people out, and it deserves its own warning. Your DNS queries can leak outside the tunnel even when your traffic routes correctly.

If your client sends DNS to a resolver reached outside the tunnel, your ISP sees the name of every site you visit, including the ones you carefully routed through the VPN. The traffic is encrypted; the lookup that preceded it is not. That defeats much of the point.

In WireGuard, the DNS = line in the client [Interface] section sets the resolver used while the tunnel is up. Point it at a resolver reachable through the tunnel if you want lookups protected. Then verify with a DNS leak test rather than assuming, because operating systems have their own opinions about resolver order and will sometimes override yours.

The verdict

Split tunneling is a genuinely useful feature for speed, local access and dual connections - as long as you remember that excluded traffic gets none of the VPN's protection. Use it deliberately for the apps that benefit, keep anything sensitive inside the tunnel, and when in doubt, route everything through the VPN.

The Windows default behaviour described here, including that force tunnel is the default configuration when no routes are specified, the manipulation of routing entries with a lower metric than other interfaces, the availability of exclusion routes, and the framing of the choice as affecting configuration, capacity planning and security expectations, is taken from Microsoft's documentation on VPN routing decisions, checked at the time of writing. Other platforms default differently; check your own client's documentation.

★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed

A VPS you fully control for tunneling & obfuscation → ContaboRoot access · open any port · run your own stack

Frequently asked questions

What is split tunneling in simple terms?
Split tunneling is a VPN feature that lets you decide which of your traffic goes through the encrypted VPN tunnel and which goes straight out over your normal internet connection. Instead of routing everything through the VPN, you split it: for example, your browser goes through the VPN while a video call or a local device connection goes direct. It's about choosing what to protect and route through the VPN, rather than all-or-nothing.
Why would I use split tunneling?
Three common reasons. Speed: traffic that doesn't need the VPN skips the extra hop, so it's faster and uses less of the VPN's bandwidth. Local access: you can reach devices on your home network - a printer, a NAS - while the VPN is still on for everything else. And dual access: you can use a local service that blocks VPNs and a VPN-only service at the same time, without toggling the VPN off. It's mostly a convenience and performance feature.
Is split tunneling safe?
It's safe as long as you understand the trade-off: anything you route outside the tunnel is not protected by the VPN. That traffic is visible to your network and ISP and uses your real IP, exactly as if the VPN weren't on. The risk is misconfiguration - excluding something sensitive by accident, or a DNS leak. For convenience it's fine; for privacy-critical use, a full tunnel (everything through the VPN) is the safer default.
Does split tunneling expose my IP?
For the excluded traffic, yes - that's the point. Connections you route outside the VPN use your real IP address and your normal connection, so the sites and services they reach see your true location and your ISP can see them. Only the traffic you send through the tunnel is hidden behind the VPN's IP. If hiding your IP for a particular app matters, make sure that app is inside the tunnel, not excluded.
How do I set up split tunneling on WireGuard?
On self-hosted WireGuard, split tunneling is controlled by the AllowedIPs setting in your client config. Setting AllowedIPs to 0.0.0.0/0 (and ::/0) routes all traffic through the tunnel - a full tunnel. Listing only specific subnets instead sends just that traffic through WireGuard and leaves the rest on your normal connection - a split tunnel. So you don't need a special 'feature': WireGuard's routing config is the split-tunneling control.