🔀 08-05: Split Tunneling and Configuration¶
📌 The Question Every VPN Client Has to Answer¶
Once a VPN tunnel is up, a client device has to decide, for every single outgoing packet: does this go through the encrypted tunnel, or does it go out directly over the regular network connection? The answer to that question is the difference between split tunneling and full tunneling.
🛣️ Full Tunneling¶
In full tunneling, all of the client's traffic is routed through the VPN — web browsing, email, streaming, everything — regardless of whether it's actually destined for a resource on the private network.
- Every packet leaves the device via the tunnel interface, gets encrypted, and travels to the VPN gateway before going anywhere else (including back out to the public Internet, if the destination isn't actually on the private network).
- The VPN gateway becomes the single choke point for all of that client's traffic.
💡 Full tunneling is the default assumption behind consumer "VPN for privacy" apps: the whole point of those products is that all your traffic appears to come from the VPN provider's exit point and is hidden from your local network/ISP, so naturally 100% of traffic needs to go through the tunnel.
Trade-offs of Full Tunneling¶
- Security benefit: the organization can monitor, filter, and apply security policy (firewall rules, malware scanning, content filtering) to literally all of the client's traffic, not just traffic bound for internal resources.
- Cost: every request — even a completely unrelated one, like checking a public weather website — has to make a round trip through the VPN gateway, adding latency and consuming the gateway's bandwidth. If a lot of remote employees are all full-tunneling, the VPN gateway can become a bottleneck.
✂️ Split Tunneling¶
In split tunneling, only some traffic goes through the VPN tunnel — typically traffic destined for the private network's address ranges — while everything else goes directly out over the client's normal (non-VPN) Internet connection.
For example, a remote-access VPN client might be configured so that:
- Traffic to
10.0.0.0/8(the corporate network) → routed through the tunnel - Traffic to everything else (Google, Netflix, random websites) → sent directly out the client's regular Internet connection, untouched by the VPN
This is exactly the routing-table mechanism described in 08-04: Building a VPN Tunnel — the client's OS routes packets to the tunnel interface only for address ranges configured to use it (AllowedIPs in WireGuard, specific routes pushed by an OpenVPN server, etc.); everything else falls through to the normal default route.
Trade-offs of Split Tunneling¶
- Benefit: far less load on the VPN gateway and lower latency for non-corporate traffic, since only relevant traffic makes the round trip.
- Cost — and this is the important security point: split tunneling creates a bridge between a trusted network and an untrusted one, on the same device, at the same time.
⚠️ The Security Tradeoff: Convenience vs. Bridging Risk¶
This is the core concept to understand about split tunneling. When split tunneling is enabled, a single device simultaneously has:
- An authenticated, encrypted connection into the trusted private network (via the tunnel).
- An unrestricted, ordinary connection out to the untrusted public Internet (via the normal route).
If that device gets compromised — say, the user visits a malicious website over their direct (non-tunneled) connection and picks up malware — the attacker now has a foothold on a device that also has a live, authenticated path into the private network. The malware doesn't need to defeat the VPN's encryption or authentication at all; it just rides along on a device that already has legitimate access. In effect, the compromised client becomes a bridge that lets an external threat reach an internal network that was supposed to be isolated from the public Internet.
💡 This is conceptually the same risk pattern as a dual-homed host that's connected to both a trusted and untrusted network at once without a firewall between them — split tunneling recreates that risk inside a single remote client device, because the device itself is simultaneously touching both worlds.
Full tunneling avoids this specific risk because all traffic — including the potentially malicious website visit — passes through the organization's gateway, where it can be inspected, filtered, or blocked by the same security controls protecting the rest of the network. Full tunneling doesn't prevent the device from getting compromised, but it does mean the organization's security stack gets a chance to see and react to the traffic that led to it.
| Full Tunneling | Split Tunneling | |
|---|---|---|
| All traffic monitored by org? | ✅ Yes | ❌ No — only tunneled portion |
| Gateway load | Higher | Lower |
| Latency for non-corporate traffic | Higher (extra hop) | Lower (direct) |
| Bridging risk (untrusted → trusted) | Low | Higher |
| Common use case | High-security environments, compliance-sensitive orgs | Convenience-focused remote access, bandwidth-constrained gateways |
⚙️ Common VPN Client Configuration Options¶
Beyond the full/split tunneling decision, most VPN clients expose a handful of other configuration knobs that materially affect security:
Routes¶
As shown above, routes determine which destination address ranges get sent through the tunnel. Misconfigured routes are a common source of both split-tunnel bridging risk and outright connectivity problems (e.g., forgetting to route traffic to the private network you're trying to reach — a mistake explicitly called out in VPN lab exercises, where forgetting the correct route entry means ping traffic to the private network never enters the tunnel at all).
DNS Settings¶
A VPN client needs to decide which DNS server handles name resolution while the tunnel is active:
- Tunneled DNS — the client uses the organization's internal DNS server, reached through the tunnel. This is important for resolving internal-only hostnames, and it also means the organization can see and control (or filter) which domains the client is looking up.
- Local DNS — the client keeps using its normal, non-VPN DNS server (e.g., its home router or ISP's resolver) even while the tunnel is active.
If DNS is not correctly routed through the tunnel, this creates a DNS leak: even though the client's actual traffic goes through the encrypted tunnel, the DNS queries that reveal which sites/hosts it's looking up leak out in the clear over the regular connection, visible to anyone watching that path. This is covered in more detail in 08-06: VPN Attacks & Weaknesses.
Kill Switch¶
A kill switch is a client-side safeguard that blocks all network traffic if the VPN tunnel unexpectedly drops. Without one, if the tunnel connection fails, most operating systems will silently fall back to sending traffic over the regular (unprotected) network connection — which defeats the entire purpose of the VPN at exactly the moment you might not notice. A kill switch instead cuts off connectivity entirely until the tunnel is restored, trading availability for the guarantee that traffic never accidentally leaves unprotected.
💡 Losing your Internet connection because the kill switch tripped is annoying. Silently sending sensitive traffic in the clear because the tunnel dropped and nobody noticed is worse. That's the tradeoff a kill switch makes explicit.
📌 Key Takeaways¶
- Full tunneling routes all client traffic through the VPN; split tunneling routes only specific destinations (e.g., the corporate network) through the tunnel, with the rest going direct.
- Split tunneling is more convenient and reduces gateway load and latency, but it creates a bridge between a trusted network and an untrusted one on the same device.
- If a split-tunneled client is compromised via its direct (non-tunneled) connection, the attacker inherits a live path into the private network — the VPN's encryption is never even attacked.
- Full tunneling lets an organization inspect and filter all of a remote client's traffic, at the cost of extra latency and gateway load.
- Routes determine which destinations use the tunnel — misconfigured routes are a common source of both connectivity failures and bridging risk.
- DNS settings matter: if DNS queries aren't routed through the tunnel, they can leak in the clear even while the "real" traffic stays protected.
- A kill switch blocks all traffic if the tunnel drops unexpectedly, preventing silent fallback to an unprotected connection.
- None of these configuration choices are automatically "right" or "wrong" — they're tradeoffs between convenience/performance and the strength of the security guarantee.