VPN SETUP GUIDES

How to Configure Split Tunneling on a Travel Router

Full-tunnel VPN is the safe default: everything goes through your home IP, everything is encrypted. But sometimes you want exceptions: the local food-delivery…

✓VPN Policy Modes on GL.iNet,✓Example Configurations That✓Verifying Each Device's Path

Quick Answer

Stick with full tunnel unless you have a specific reason to split: everything goes through your home IP, no surprises. When you do split, use per-device rules as the foundation and short domain exceptions only for narrow cases. Misconfigured split tunneling is worse than none, which is why HomeIPVPN designs and verifies policies per device.

Default posture: default-deny (everything tunneled except exceptions) for remote work; never default-allow with sensitive traffic.
Per-device over per-domain: device rules are durable and auditable; domain rules rot as services change CDNs.
Guests: route guest devices direct so their traffic patterns are never associated with your home IP.
Verify every path: tunneled devices show home IP, bypassed devices show local IP, and re-test after firmware updates.

How to Configure Split Tunneling on a Travel Router

Full-tunnel VPN is the safe default: everything goes through your home IP, everything is encrypted. But sometimes you want exceptions: the local food-delivery app that only works on a local IP, the 4K stream that stutters through your home upload cap, the video call that would rather take the direct path. Split tunneling on a travel router lets you choose, per device or per destination, what uses the tunnel and what goes direct. Here's the full split tunneling travel router setup: how GL.iNet's policy modes work, practical configurations, and how to verify each path.

VPN Policy Modes on GL.iNet, Explained

GL.iNet routers (and OpenWrt more broadly) offer VPN policies that control which traffic enters the tunnel. The usual modes:

Global / full tunnel. Everything from every device goes through the VPN. The default, and the right choice when in doubt. Maximum protection, maximum consistency: every device presents your home IP.
Per-device (MAC-based) policies. Choose which devices use the tunnel and which bypass it. The work laptop goes through the VPN; the Chromecast streaming local content goes direct. Simple to reason about, coarse in control.
Per-domain / per-IP policies. Route specific domains or IP addresses through (or around) the tunnel. Your bank's domain via home IP; everything else direct. Or the reverse: everything via tunnel except the streaming CDN. Fine-grained, but needs maintenance as services change IPs.
Custom routing rules. For the ambitious: policy-based routing with your own rule sets. Powerful, and a good way to spend a Saturday if you enjoy that sort of thing.

The mental model that keeps this sane: default-deny vs. default-allow. Either everything goes through the tunnel except your exceptions (default-deny: safer, recommended), or everything goes direct except what you route into the tunnel (default-allow: more convenient, easier to leak something sensitive by forgetting to include it). For remote work, default-deny with narrow exceptions is the only posture I'd recommend. The convenience of default-allow isn't worth the "oops, that was supposed to be tunneled" discovery.

Example Configurations That Actually Make Sense

1. Work via home IP, streaming direct. The classic. Laptop, phone, work devices: full tunnel. The TV stick or tablet used for local streaming: direct. Rationale: streaming eats bandwidth and doesn't need your home IP (or actively prefers the local catalog). Keep work boring and consistent; let entertainment take the fast path.

2. Everything via tunnel except video calls. If your home upload is thin and calls to distant colleagues lag through the scenic route, exempt your conferencing apps' domains from the tunnel. The call takes the direct path (lower latency); everything else keeps the home IP. Verify the exempted domains actually cover the call traffic: Zoom/Meet/Teams use multiple domains and CDNs, and missing one means half the call still tunnels.

3. Banking and SSO always tunneled, nothing else special. Invert the usual thinking: instead of listing what bypasses, ensure the sensitive stuff is pinned to the tunnel even if you later widen the bypass list. Some setups let you pin specific domains to the VPN as an override above the bypass rules. Belt and suspenders for the things that trigger fraud alerts.

4. Guest device quarantine. A colleague's laptop or a friend's phone joins your travel network: route guests direct, keep your devices tunneled. Their traffic doesn't need your home IP, and if their device is compromised, its traffic isn't associated with your residential address. Good hygiene, easy to configure per-device.

5. The "local services" exception list. Food delivery, ride-hailing, local banking apps that demand a local IP: these go direct by domain. Keep the list short and review it occasionally; every exception is a small hole in the consistency story, so each one should earn its place.

A warning about domain-based rules: services change their domains and CDN endpoints regularly. A rule that worked in March might miss half the traffic by September. Per-device rules are more durable (devices don't change identity), which is why I lean toward device-based splitting for the big decisions and domain-based only for narrow cases.

Verifying Each Device's Path

Split tunneling misconfigured is worse than no split tunneling: it creates confident wrongness, where you believe traffic is tunneled and it isn't. Verify every path, not just the tunnel:

List your intended policy on paper first. Device A: tunnel. Device B: direct. Domain X: tunnel. Five lines, plain language. If you can't write it down, you don't understand your own config.
Check the tunneled devices. From each: IP check shows home IP, DNS leak test shows tunneled resolver, WebRTC test clean. The full battery, same as a full-tunnel setup.
Check the bypassed devices. From each: IP check shows the local IP (hotel/cellular), confirming the bypass works. If a "direct" device shows your home IP, the bypass rule isn't matching: fix it before you rely on the distinction.
Test the domain rules with real traffic. Visit the domains in question and check which path they took (the router's traffic logs or a quick IP check from a test page). Domain rules are the most likely to silently fail; verify, don't assume.
Re-verify after changes. New device joins the network: which policy caught it? (Default policies apply to unknown devices: make sure the default is the tunnel, not direct.) Firmware update: policies intact? Service changed CDN: domain rule still matching?
Watch for the kill-switch interaction. If the tunnel drops, what happens to bypass traffic? Usually it continues direct (it's not in the tunnel anyway), but tunneled devices should be blocked until the tunnel returns. Confirm the kill switch covers the tunnel policy and doesn't accidentally strand bypass devices.

FAQ

Does split tunneling weaken my security? +

It reduces coverage by design: bypassed traffic gets no tunnel encryption and no home IP. The security question is whether the right traffic is bypassed. Work, banking, SSO: tunneled, always. Local food delivery: bypass is fine. The risk is misconfiguration, not the concept.

Which is better: per-device or per-domain rules? +

Per-device for the big strokes: durable, easy to audit, hard to get subtly wrong. Per-domain for narrow exceptions: precise but brittle as services change infrastructure. Most good setups use per-device as the foundation with a short domain list for special cases.

Can split tunneling improve speed? +

Yes, meaningfully. Traffic that doesn't need the tunnel (bulk downloads, local streaming) skipping the encryption and the scenic route via home frees bandwidth and reduces latency for what remains. It's one of the legitimate performance tools, alongside hardware upgrades.

What happens to bypassed traffic if the VPN drops? +

It keeps flowing direct: it was never in the tunnel. That's by design, but be sure it's your design: sensitive traffic must never be in the bypass set, because the bypass set has no safety net.

Should guests on my travel router use the tunnel? +

My default: no. Route guest devices direct. Their traffic patterns aren't yours, and you don't want a guest's compromised phone or torrent habit associated with your home IP. Your devices stay tunneled; guests get plain internet. Everyone's incentives align.

Do I need split tunneling at all? +

Honestly? Many travelers don't. Full tunnel is simpler, safer, and the performance cost is often negligible. Add split tunneling when you have a specific reason: a service that needs local IP, a bandwidth crunch, a latency problem on calls. "Might be nice" isn't a reason; each exception is complexity you'll maintain.

Need Help Setting This Up?

Split tunneling is one of those features that's easy to enable and surprisingly easy to get subtly wrong, and "subtly wrong" here means traffic going somewhere you didn't intend. If you'd like it configured and verified properly, our done-for-you setup includes policy design and per-device testing: https://homeipvpn.com.

How to Configure Split Tunneling on a Travel Router