TorSentinel Team •
Deep Dive
Split Tunneling
VPN
Routing
Privacy
Split Tunneling Explained:
Routing Patterns, Risks, and Guardrails
Split tunneling lets you choose which apps or destinations use a VPN tunnel and which do not. Done well, it reduces latency and avoids overloading a single encrypted pipe. Done poorly, it creates side channels that quietly weaken privacy. This guide explains practical routing patterns, risks, and the guardrails that keep things simple.
TorSentinel Team
·
Updated 2025
·
8 min read
·
Intermediate — Advanced
? What split tunneling is
Instead of forcing all traffic through a VPN adapter, split tunneling allows a subset to bypass the tunnel. Policies can be per app, per destination, or per subnet. The usual goals are lower latency for real-time traffic and reduced load on the encrypted link.
✓ When it makes sense
Performance
Keep latency-sensitive traffic direct while bulk or sensitive flows stay in the tunnel.
Local access
Reach LAN devices or region-locked services without disconnecting the VPN entirely.
Stability
Reduce congestion on a single encrypted path during heavy transfers like torrents.
✕ When it's a bad fit
Strict privacy models
Environments that require one trusted egress by policy — splits create additional attack surface.
Mixed DNS paths
If name resolution flips between resolvers, apps may leak metadata outside the intended path.
Unmanaged hosts
Shared or loosely managed systems where users can create ad hoc exclusions without oversight.
🔀 Common routing patterns
A
Per-app split
Choose specific apps that bypass or use the tunnel. Simple mental model — easy to audit and explain. Recommended starting point.
B
Destination split
Route subnets or domains directly while the rest stays tunneled. Powerful but requires careful DNS alignment and ongoing review as services change.
C
Inverse split
Default direct, only selected apps go through the tunnel. Useful on constrained hardware where only a few apps need privacy protection.
⚠ Risk scenarios and guardrails
| Scenario | Why it happens | Guardrail |
|---|---|---|
| App starts before tunnel | Race condition at boot or resume from sleep | Delay start until adapter up; firewall deny outside tunnel |
| Mixed DNS path | System resolver flips or DNS is included in the split | Pin resolver; route DNS consistently with traffic path |
| Local services unreachable | All traffic forced into tunnel including LAN | Add explicit LAN subnets to the direct list |
| Unexpected IPv6 route | IPv6 policy differs from IPv4 tunnel scope | Set explicit IPv6 stance per app or per OS — never leave mixed |
⚖ Speed vs privacy: finding the balance
→
If the privacy requirement is strict — use full tunnel and avoid splits entirely
→
If the need is mixed — use per-app split for specific tools and keep DNS policy consistent
→
Only use destination splits if you control the names and subnets — or have monitoring in place to catch changes
⚙ Implementation tips
1
Define the trusted adapter
Know the VPN interface name and bind sensitive apps to it where possible — this is the anchor point for all other rules.
2
Write deny rules first
Firewall policy should fail closed if the adapter is down. Start with deny, then add the specific allows you need.
3
Keep DNS with the flow
Route name lookups the same way as the app traffic. A DNS query that follows a different path than the data it's resolving is a side channel.
4
Be explicit about IPv6
Permit or disable it per policy. Avoid half-configured states where IPv4 goes through the tunnel but IPv6 resolves direct.
5
Audit after every change
Test with a small workload and verify routes before and after reboot or sleep. Split configs are silent when they drift.
📋 Policy checklist
✓
Bind sensitive apps to the VPN adapter when possible.
✓
Deny outside path by default — allow only intended flows explicitly.
✓
Align DNS with the chosen route and monitor for resolver flips.
✓
Set an explicit IPv6 policy and keep it consistent with IPv4.
✓
Delay autostart until the trusted adapter is confirmed up — test after every reboot.
FAQ Frequently asked questions
Does split tunneling always reduce privacy?
No. Split tunneling is a tool — not a vulnerability by itself. It can preserve privacy if guardrails are in place: binding, deny-outside-path, and DNS alignment. Problems appear when traffic or DNS escapes the intended route without detection.
Is per-app split safer than destination split?
Usually yes, because it is easier to reason about and audit. Destination splits require careful DNS handling and continual review as services change IP addresses or add CDN nodes — a destination that was safe last month may route differently today.
What should I test after enabling a split?
Verify adapter binding, firewall behavior when the VPN is down (fail-closed test), DNS resolver path, and IPv6 route. Reboot and repeat every test to catch race conditions at startup.
Verify your routing is actually working
Free torrent IP check — no signup
See exactly which IP the swarm detects from your client. The fastest way to confirm your split config is routing torrent traffic correctly.