# https://tunnels.io/learn/what-is-split-tunneling

[Home](https://tunnels.io/) / [Learn](https://tunnels.io/learn) / What is split tunneling?

Concepts

# What is split tunneling?

Split tunneling is a VPN setting that sends only some of a device's traffic through the encrypted VPN tunnel and lets the rest go straight out over the local internet connection. Administrators choose the split by application, by destination IP range, or by domain. It cuts latency and gateway load, at the cost of leaving the direct traffic uninspected.

## What does split tunneling mean in plain terms?

A VPN client normally claims the default route, so every packet the machine sends leaves through the tunnel, including a video call and an operating system update that have nothing to do with work. Split tunneling narrows that claim. The client installs routes only for the networks the organization actually cares about, and everything else keeps using the ordinary default gateway on the local link.

## How does split tunneling work?

Almost all of it is routing table work. A full tunnel adds a route covering 0.0.0.0/0 that points at the virtual interface and wins over the physical gateway; a split tunnel installs only specific prefixes, such as 10.0.0.0/8, and leaves the default route alone. In WireGuard the split is expressed as the AllowedIPs list on the peer; in OpenVPN it is whether the server pushes redirect-gateway. DNS is configured alongside the routes, so internal names resolve on the internal resolver while public names do not.

## What can traffic be split on: apps, addresses, or domains?

Address-based splitting matches on destination IP prefixes and is the most predictable, because the kernel routing table does all the work. Application-based splitting matches on the process opening the connection, which needs a hook in the operating system, so support and reliability vary by platform. Domain-based splitting resolves hostnames and programs routes from the answers; it reads well in a policy document and is the most fragile in practice, because CDN addresses rotate and many unrelated hostnames sit behind one address.

| | Full tunnel | Split tunnel |
| --- | --- | --- |
| Default route | Points at the VPN interface | Stays on the physical gateway |
| What the security stack sees | Every connection the device makes | Only traffic to the listed destinations |
| Path to a public website | Device, VPN gateway, then out | Straight out from the device |
| Load on the VPN concentrator | All user traffic | Internal traffic only |
| If the device is compromised | One path, and it is inspected | Two live paths, one of them uninspected |
| Usual complaint | Saturated gateway, slow calls | A destination nobody listed goes unwatched |

## Why do people enable split tunneling?

Bandwidth and latency, mostly. Hairpinning a video call or a multi-gigabyte update through a corporate concentrator burns gateway capacity and adds a detour in each direction, which is why real-time media is one of the first things organizations route around the tunnel. The second reason is local access: enterprise clients frequently block local LAN access while connected as a hardening measure, which puts the user's own printer or NAS out of reach until they disconnect.

## What are the security trade-offs?

Everything outside the tunnel is invisible to whatever sits at the corporate egress: web filtering, data loss prevention, malware inspection, and the logs an incident responder will want afterwards. The device also holds two live paths at the same time, one into the internal network and one onto whatever untrusted network it is sitting on, so a compromised endpoint becomes a usable bridge between them. Split tunneling does not so much create these risks as move the enforcement point from the network to the endpoint, and that is only an improvement if the endpoint genuinely has an EDR agent, a local firewall policy, and a managed DNS resolver.

## What is inverse split tunneling?

Inverse split tunneling flips the default. Rather than listing what goes through the VPN and letting everything else out directly, everything goes through the VPN and you list the specific destinations allowed to bypass it. The practical difference shows up on a destination nobody thought about: on an inclusion list it is unprotected, on an exclusion list it is protected. Vendors do not agree on the labels, so read the policy itself and work out which of the two lists is the exception.

## When should you not use split tunneling?

If a compliance regime requires that all user traffic is inspected, or that it leaves from a known set of source addresses, split tunneling defeats the control and should stay off. The same holds on unmanaged or personal devices, where nothing is left to enforce policy once traffic exits outside the tunnel. It is also worth avoiding where split-horizon DNS is in use unless resolver policy gets the same care as the routes, because the usual symptom is an internal hostname resolving to a public address and failing in a way nobody can reproduce on the office network.

## Is split tunneling the same as a reverse tunnel?

No, and the two get confused because both involve deciding which traffic goes where. Split tunneling is about outbound traffic from a device that already has internet access, and the decision is which packets get encrypted toward a VPN gateway. A reverse tunnel is about inbound reach: something on the public internet needs to open a connection to a service on a machine that has no public address, so the machine dials out first and the connection is reused in the other direction.

## Related reading

[What is a VPN tunnel? The encapsulation that split tunneling decides to use or skip, and where a VPN stops being the right tool.](https://tunnels.io/learn/what-is-a-vpn-tunnel) [What is tunneling? The general idea underneath all of it: carrying one protocol inside another to cross a network that would not otherwise pass it.](https://tunnels.io/learn/what-is-tunneling)

Everything else is on the [Learn](https://tunnels.io/learn) index.

## Common questions

### Is split tunneling safe to enable at work?

It depends entirely on what the endpoint can enforce on its own. On a managed laptop with EDR, a local firewall policy and a filtered DNS resolver, splitting bulk or real-time traffic out of the tunnel is a normal and defensible choice. On an unmanaged device, or where a regulation requires inspection of all user traffic, it removes a control you are relying on and should stay off.

### Does split tunneling make my VPN faster?

It makes the traffic you exclude faster, because those packets no longer take a detour through the VPN gateway and no longer carry encapsulation overhead. It also frees capacity on the concentrator, which indirectly helps the traffic that stays inside the tunnel. Connections to internal systems still travel the same path they did before.

### What is the difference between split tunneling and inverse split tunneling?

Split tunneling lists what goes through the VPN and lets everything else out directly. Inverse split tunneling sends everything through the VPN and lists the specific destinations permitted to bypass it. The second form is the safer default, because a destination nobody anticipated is protected rather than exposed.

### Do I need a VPN to share a local development server?

No. A VPN gives your device access to a remote network, which is the opposite direction from what sharing needs. To let a colleague, a phone, or a webhook provider reach a server on your machine, you want a reverse tunnel that gives that one service a public HTTPS URL, without joining anything to a network.

### Will a tunnel client interfere with my corporate VPN?

A reverse tunnel client of the kind tunnels.io uses does not create a virtual network interface or modify your routing table, so it has no split tunneling policy of its own and does not compete for the default route. It makes one outbound connection like any other application. If your VPN is in full tunnel mode, that connection simply travels inside the VPN.

## Where does tunnels.io fit?

Split tunneling is a decision about outbound traffic on a device that already has connectivity. tunnels.io answers the inbound question instead: how something on the public internet reaches a server running on your machine. The client opens a single outbound connection to our edge and forwards traffic for one local port, so there is no virtual interface, no routing table change, and no default route to argue over with a corporate VPN.

It is not a VPN replacement, and it is not trying to be. The engine carries HTTP, HTTPS and TCP only; there is no UDP, no ICMP, and no layer 3 network for your machine to join. If what you actually need is a mesh network between devices, where split tunneling is configured with exit nodes and subnet routers, read [tunnels.io vs Tailscale](https://tunnels.io/compare/tailscale) before you pick either one.

If a public HTTPS URL for one local service is the thing you want, the free Basic plan is $0, includes 4 GB of transfer a month and one tunnel on a random URL, and shows no interstitial page to your visitors. TCP tunnels and reserved subdomains start on Pro at $4 a month.

[Get started free →](https://tunnels.io/get-started) [See pricing](https://tunnels.io/pricing)