Linux Split Tunneling: 7 Essential Routing Methods

Linux split tunneling lets you choose which traffic uses a VPN and which traffic stays on your normal or local network route. On Linux, that decision can happen inside a VPN app, WireGuard, policy routing, namespaces, OpenVPN, local routes, or the router. What matters is knowing where each packet goes and what happens when the VPN stops.

I use Linux split tunneling because my Parrot OS VM needs protected internet access while isolated lab networks stay local. DNS, IPv6, and failure handling also need to be deliberate. For me, this is a practical routing problem, not a checkbox I enable and forget.

Key Takeaways

• Linux split tunneling is routing control first. The VPN encrypts traffic that enters the tunnel, but Linux still decides which traffic reaches that tunnel.
• Split tunneling WireGuard Linux setups are clean when the rule is destination-based because AllowedIPs can define which networks belong to a peer.
• OpenVPN split tunneling works well when you selectively ignore a pushed default route and add only the routes you actually want.
• Proton VPN split tunneling Linux support is convenient on supported native GUI packages, while unusual or unsupported distributions deserve extra testing.
• VPN split tunneling security depends on IP routing, DNS, IPv6, firewall policy, and what protected traffic does when the tunnel disappears.
• I prefer the simplest method that expresses the rule clearly. Networking already has enough ways to become interesting without my help.

Affiliate disclosure: Proton Unlimited is the primary affiliate in this guide because I already use Proton VPN in my own network and lab. If you buy through my link, I may earn a commission at no extra cost to you. That relationship does not change the routing checks I recommend.

Proton Unlimited combines Proton VPN, Proton Mail, Proton Drive, and Proton Pass in one subscription. If several Proton services already fit your privacy or lab workflow, the bundle is often the more practical option.

What Linux Split Tunneling Actually Does

A full-tunnel VPN makes the VPN the preferred internet path. Linux split tunneling deliberately keeps a second path for selected traffic. The split can be based on destination, source network, application, namespace, or device.

Encryption and routing are different jobs. WireGuard or OpenVPN protects packets that enter the tunnel; Linux decides which interface or table receives them. If the route never points toward the VPN, the tunnel cannot protect that traffic.

A Linux VPN with split tunneling needs a clear policy before commands. I write the intent in plain language first: one app uses the VPN, my lab subnet stays local, and protected traffic must not fall back if the tunnel dies. Once that rule is clear, the technical method is easier to choose.

HackersGhost Note: I treat Linux split tunneling as a routing policy that happens to use a VPN. That mindset saves me from blaming the VPN client for every strange route, DNS request, or local connection. I ask “which rule wins?” before I ask “what is broken?”

Linux Split Tunneling vs Full Tunneling

Full tunneling is easier to reason about because most traffic has one path. Linux split tunneling adds flexibility when local devices, VMware networks, or selected apps should stay outside the commercial VPN route.

I do not see split tunneling as automatically safer or less safe. If a browser is intentionally tunneled and a local printer is intentionally direct, the design can be sensible. If a broad exception sends protected traffic outside the VPN, it is not. Linux split tunneling is only as good as the rule you define.

In my lab, vulnerable targets stay on isolated local networks. Sending their traffic through a public VPN would add confusion without useful benefit. Linux split tunneling keeps those local paths local.

Method 1: Proton VPN Split Tunneling Linux Setup

The easiest Linux split tunneling method is a VPN client that understands application rules. Proton VPN split tunneling Linux support is available in the native GUI on supported Ubuntu, Fedora, and Arch setups, with an optional Debian setup. Include mode tunnels only selected apps; Exclude mode keeps selected apps outside the VPN.

On a supported desktop, I would start there. Disconnect the VPN, set the rule, reconnect, and restart the included or excluded apps. Then verify public IP and DNS. Native Linux split tunneling is convenient, but I still test the result.

Proton VPN split tunneling Linux needs more care on unsupported distributions. Proton reports that its apps can work on Kali, but support is limited. Parrot OS is also outside the core support list, so I verify advanced GUI behavior on my main Parrot VM.

The Snap build is fine for basic use, but its sandboxing means split tunneling is unavailable there. If Linux split tunneling is the reason for installing Proton, use a native package path that supports the feature.

Method 2: Split Tunneling WireGuard Linux With AllowedIPs

Split tunneling WireGuard Linux configurations are clean when the policy is destination-based. AllowedIPs associates address ranges with a WireGuard peer and helps determine which destinations are sent to it. Broad ranges such as 0.0.0.0/0 and ::/0 describe full-tunnel coverage; narrower ranges create a split.

[Peer]
PublicKey = <VPN_SERVER_PUBLIC_KEY>
Endpoint = <VPN_SERVER_IP>:<PORT>
AllowedIPs = 203.0.113.0/24, 198.51.100.25/32

Those are documentation examples, not real targets. Only those destinations belong to the peer while other traffic follows the host route. This makes WireGuard a strong Linux split tunneling option when you know the networks in advance.

An IP route does not naturally understand application names. For app-level Linux split tunneling, I use a namespace or the VPN client’s native selection instead of forcing destination routing to solve the wrong problem.

The WireGuard homepage is my first external reference. Its cryptokey routing explanation is the right mental model for split tunneling WireGuard Linux and for understanding why AllowedIPs matters.

Method 3: Linux Split Routing With Policy Rules

Linux split routing becomes useful when one routing table is not enough. Policy rules can select another table by source address, destination, or firewall mark. I use that when a gateway or defined traffic class needs its own VPN route.

A source-based rule does not mean “this application.” The following example is for packets that genuinely originate from the example subnet, such as traffic forwarded by a Linux gateway:

sudo sh -c 'echo "200 vpn" >> /etc/iproute2/rt_tables'
sudo ip route add default dev wg0 table vpn
sudo ip rule add from 192.0.2.0/24 table vpn

192.0.2.0/24 is a documentation subnet. This Linux split routing rule sends traffic from that source range to the vpn table; it does not select a browser. For local apps, I prefer a namespace.

Firewall marks can take Linux split tunneling further, but they add moving parts. The mark needs a matching policy rule, the chosen table needs a usable route, and the firewall must agree. I inspect the live state instead of trusting a copied snippet.

HackersGhost Note: ip rule selects routing logic. It is not a kill switch. If protected traffic must fail closed, I define that behavior separately with firewall policy and then test the tunnel failure on purpose.

Linux VPN Kill Switch: 7 Essential Safety Checks

Method 4: Linux VPN With Split Tunneling via Namespaces

For strict process separation, network namespaces are my favorite manual option. A namespace gets its own interfaces and routing context, so selected processes can have WireGuard as their only internet path. This gives a Linux VPN with split tunneling a clear boundary between host traffic and VPN-only traffic.

WireGuard is elegant here because its encrypted UDP socket stays in the namespace where the interface was created, even after the interface moves. The physical network can remain on the host while cleartext traffic inside the VPN namespace uses WireGuard.

sudo ip netns add vpnspace
sudo ip link add wg-vpn type wireguard
sudo ip link set wg-vpn netns vpnspace
sudo ip -n vpnspace link set lo up

sudo ip netns exec vpnspace wg setconf wg-vpn /etc/wireguard/wg-vpn.conf
sudo ip -n vpnspace addr add <VPN_ADDRESS> dev wg-vpn
sudo ip -n vpnspace link set wg-vpn up
sudo ip -n vpnspace route add default dev wg-vpn

The config used with wg setconf contains peer keys, endpoint, and AllowedIPs; addressing and DNS are handled separately. For Linux split tunneling, I make resolver behavior explicit inside the namespace.

sudo mkdir -p /etc/netns/vpnspace
echo "nameserver <VPN_DNS_IP>" | sudo tee /etc/netns/vpnspace/resolv.conf

sudo ip netns exec vpnspace curl https://ifconfig.io

I like this because the boundary stays obvious: a normal shell uses the host, while ip netns exec vpnspace uses the namespace. That is easier for me to audit than a forgotten pile of exclusions.

I use Proton VPN with WireGuard in my own network. Proton Unlimited adds Proton Mail, Proton Drive, and Proton Pass under the same subscription, which can make sense when the VPN is only one part of your privacy setup.

Method 5: OpenVPN Split Tunneling With Selective Routes

OpenVPN split tunneling is useful when you already have OpenVPN profiles or need mature route controls. A server can push redirect-gateway for a full tunnel. For a split, I can ignore that default-route instruction and add only the routes I need.

pull-filter ignore "redirect-gateway"
route 203.0.113.0 255.255.255.0
route 198.51.100.25 255.255.255.255

Split Tunneling OpenVPN Linux: Keep the Rule Narrow

I prefer a narrow rule because it keeps Linux split tunneling understandable and avoids discarding useful settings I never intended to replace.

I prefer this targeted approach over blindly adding route-nopull, which also blocks pushed routes and DHCP-style options such as DNS settings. For split tunneling OpenVPN Linux, filtering only the default route can preserve more useful server configuration.

After changing OpenVPN split tunneling, I test one tunneled destination, one direct destination, and DNS. That quickly tells me whether the split matches the plan.

The OpenVPN homepage is my second external reference. Its route controls remain useful when a setup is already built around OpenVPN.

Method 6: VPN Split Tunneling DNS and Local Lab Access

VPN split tunneling DNS deserves its own check because application traffic and name resolution can use different paths. A browser may use the VPN while DNS is handled by the host or a local resolver. That can be intentional, but it should never be a surprise in a Linux split tunneling design.

My local lab adds another reason for Linux split tunneling. Vulnerable VMware machines need to remain reachable directly from Parrot OS, while ordinary internet traffic can use the VPN. Before adding any route, I ask Linux what it would already do:

ip route get <LAB_TARGET_IP>

If Linux already selects the isolated lab interface, I do not add another route just to feel productive. If the route is correct but the target is unreachable, I check the VPN client’s local-network policy and firewall next. A more-specific local route can beat a default VPN route, but a kill switch can still block the packet.

This is where VPN split tunneling security becomes practical: routing and firewall policy must agree. A correct route can still be blocked, while a permissive firewall cannot repair a wrong route. I test the layers separately.

Method 7: Router-Level Linux Split Tunneling

The seventh option moves the decision to the router. On hardware with VPN client and traffic-policy support, selected devices or destinations can use the VPN while other traffic stays on the normal WAN. That is cleaner than rebuilding Linux split tunneling on every VM when the rule belongs to a whole device.

My Cudy WR3000 is the VPN-facing router and uses Proton VPN over WireGuard. I can add Secure Core when I want an extra privacy hop. My TP-Link Archer C6 stays separate for vulnerable lab work, disconnected from the normal modem path and linked directly to my laptop.

I do not treat the router as a replacement for host-level Linux split tunneling. The layer should match the rule. If an entire VM or device belongs behind the VPN, router policy is neat. If one app on Parrot should be tunneled while another stays direct, the decision belongs on Parrot.

How I Use Linux Split Tunneling in My Own Lab

My main machine is a second-hand HP EliteBook that I upgraded from 16GB to 32GB of RAM. It runs the latest Windows version as the host, and I chose VMware rather than VirtualBox. I keep Kali Linux and Parrot OS available, although Parrot is the environment I use most.

Inside VMware I run vulnerable distributions and web-security targets on isolated networks. Linux split tunneling keeps lab targets local while VPN traffic uses the intended tunnel. The two paths have separate jobs.

The Cudy WR3000 handles Proton VPN WireGuard for devices behind it. Parrot can still use its own Linux split routing for more precise guest-level rules. The TP-Link Archer C6 gives me a separate vulnerable network for sniffing and defensive experiments without attaching it to the normal modem path.

HackersGhost Note: My lab became easier to troubleshoot when I stopped thinking in terms of “VPN on” and “VPN off.” I now think in paths: host internet, VPN internet, isolated lab, and router-level VPN. Linux split tunneling is simply the rulebook that keeps those paths intentional.

VPN Split Tunneling Security: How I Test It

A Linux split tunneling setup is not finished when the VPN says Connected. I trust it after routes, public IP, DNS, IPv6, local access, and forced failure all match the policy I intended.

Check Linux Split Routing First

ip route get 1.1.1.1
ip route get <LOCAL_OR_LAB_IP>
ip rule show
ip route show table all

These commands tell me what Linux believes before a browser adds caching, proxies, extensions, and other distractions. For a split tunneling WireGuard Linux setup, I also run wg show so I can confirm the interface, peer, latest handshake, and transfer state.

Test the Public IP on Both Paths

If one process should use the VPN and another should go direct, I test both. With a namespace, I compare a normal curl request with one launched through ip netns exec vpnspace. If both routes match when they should differ, the Linux split tunneling policy is wrong.

Check VPN Split Tunneling DNS Separately

VPN split tunneling DNS is a separate test. I check the resolver on tunneled and direct paths. DNS outside the VPN is not automatically a leak if I designed it that way, but it is a leak from my intended policy if protected lookups were meant to stay inside.

Is Split Tunneling Safe When the VPN Drops

Is split tunneling safe after a disconnect? Only if failure behavior matches your rule. I stop the VPN and watch protected traffic. If it falls back to the normal route, the split works but is not fail-closed. If fallback is unacceptable, I add firewall enforcement and test again.

Do Not Forget IPv6

An IPv4-only Linux split tunneling policy can look correct while IPv6 takes another route. I define both address families or deliberately disable the unused path. One IPv4 check is not the whole story.

HackersGhost Note: My boring five-part test is route, public IP, DNS, IPv6, then forced disconnect. Boring is good here. If all five results match the design, I trust Linux split tunneling far more than I trust a green status icon.

How to Test DNS & WebRTC Leaks: 7 Sneaky Checks

Common Linux Split Tunneling Mistakes I Avoid

• Treating an ip rule as an application selector. A source-based rule matches a source address, not the name of the program that created the packet.
• Testing only the tunneled path. Linux split tunneling creates at least two intended outcomes, so I test both sides.
• Ignoring IPv6. A clean IPv4 route does not prove IPv6 follows the same policy.
• Forgetting resolver behavior. VPN split tunneling DNS can differ from application traffic and needs its own check.
• Combining a kill switch with direct exceptions without testing. Firewall enforcement can block the local or direct traffic you intentionally excluded.
• Using 0.0.0.0/0 and calling it a split. In a normal WireGuard setup, that is a full IPv4 range unless other routing policy changes the outcome.
• Copying nftables marks without understanding them. A mark only matters when another rule or table actually uses it.

Real Uses for a Linux VPN With Split Tunneling

A Linux VPN with split tunneling does not need an exotic reason to exist. The ordinary use cases are useful enough:

• Home lab: I keep VMware targets and isolated subnets local while selected internet traffic uses the VPN.
• Public Wi-Fi: sensitive apps can use the VPN while a separate browser handles a captive portal directly when necessary.
• Remote work: a work network can use its required tunnel while local devices remain reachable, if company policy allows it.
• Performance-sensitive traffic: a video call can remain direct while a browser, terminal, or another selected app uses the VPN.
• Testing: I can compare direct and VPN behavior from the same Linux host without rebuilding the entire network between checks.

What I like most about Linux split tunneling is clarity. When each path has a purpose, I can isolate whether a failure belongs to the VPN, local route, DNS, firewall, or lab network instead of changing everything at once.

My Take on Linux Split Tunneling

Linux split tunneling is worth learning because each method solves a different problem. Proton’s native app is easiest on supported desktops; WireGuard fits known destinations; policy routing handles source or mark rules; namespaces isolate processes; OpenVPN split tunneling fits existing OpenVPN setups; and router rules fit whole devices.

I would not stack all seven methods together just because Linux allows it. I choose the smallest Linux split tunneling design that expresses the rule, then test it until I can explain the result without waving at the terminal and saying “Linux.”

Proton fits my setup because I already use Proton VPN over WireGuard on my Cudy router and manual Linux split tunneling inside Parrot. The VPN service and Linux routing complement each other; they are not the same layer.

Proton Unlimited bundles Proton VPN, Proton Mail, Proton Drive, and Proton Pass in one subscription. If Proton already covers several parts of your privacy workflow, the combined plan can be simpler than managing those services separately.

Frequently Asked Questions