Beta Feature: Split Tunneling is currently in beta. It is functional and ready for testing, but you may encounter rough edges. Feedback and bug reports are welcome.
Split Tunneling lets you route specific apps or connections through a different network interface, overriding the default routing the operating system would otherwise apply.
Your operating system has a default route - a rule that says "send all traffic through this interface unless told otherwise." In most cases that interface is your Wi-Fi or Ethernet adapter. When a VPN is running, the VPN software replaces (or overrides) that default route so that all traffic flows through the VPN tunnel.
Split tunneling lets you override the default route on a per-app (or per-destination) basis. Instead of every connection going through whatever interface the OS would normally pick, you can direct specific apps or specific destinations to exit through a different network interface of your choosing - your physical Wi-Fi adapter, a secondary Ethernet port, a mobile hotspot, or any other interface available on the device.
The most common use case is VPN bypass: while a VPN is active and handling the majority of your traffic, selected apps are sent through the regular physical connection instead. But split tunneling is not limited to VPNs - it is equally useful any time you want to control which interface a particular app uses, regardless of what the default system routing looks like.
Portmaster handles all of this automatically in the background. Apps do not need any special configuration - they simply connect as usual, and Portmaster ensures the traffic leaves through the right interface.
Some common scenarios:
Portmaster sits between your apps and the network, inspecting every outgoing connection. When a connection belongs to an app that has split tunneling enabled, Portmaster quietly steps in before the connection leaves your device:
The app itself is completely unaware of the proxy - it just sees its connection succeed as normal. There is no need to configure the app, install a separate driver, or change any system settings.
Supported protocols: Standard web traffic (TCP) and real-time traffic such as video calls or gaming (UDP), both over IPv4 and IPv6. IPv6 is only handled when IPv6 is available and configured on the selected interface.
Low-level protocols like ICMP (used byping) are not affected by split tunnel rules.
Split tunneling is configured through four settings. Most of them can be set at two levels:
| Setting key | splittun/enable |
|---|---|
| Default | Off |
This master switch must be enabled in Portmaster's global settings before any app-level split tunnel settings take effect. When disabled, the split tunnel module is completely shut down and no traffic is rerouted.
| Setting key | splittun/use |
|---|---|
| Default | Off |
Enables split tunneling. When set globally, it applies to all apps by default. You can then override it per-app - for example, enable it globally and exclude specific apps, or keep it off globally and enable it only for selected apps.
| Setting key | splittun/networkInterface |
|---|---|
| Default | (empty - auto-detect) |
Specifies which interface traffic should exit through. Set it globally to apply one interface to all split-tunnelled apps, or override it per-app to send different apps through different interfaces. You can identify an interface in three ways:
Ethernet or Wi-Fi on Windows; eth0, wlan0, enp3s0 on Linux.192.168.1.1, 10.0.0.100:1A:2B:3C:4D:5EIf left empty, Portmaster attempts to automatically detect the best physical (non-VPN) interface for the connection. This works in most cases, but manual configuration is more reliable if auto-detection behaves unexpectedly.
Important: If the specified interface cannot be found or has no usable address, the connection will be dropped rather than silently falling back to the default route.
| Setting key | splittun/usagePolicy |
|---|---|
| Default | (empty - all connections split-tunnelled) |
Fine-grained rules that decide which connections are actually split-tunnelled. Can be set globally and also per-app. Because this setting is stackable, per-app rules are merged on top of the global rules rather than replacing them entirely. Rules follow the same endpoint-list syntax used elsewhere in Portmaster (IP addresses, domains, CIDR blocks, countries, …).
Each rule entry is either an Allow (+) or Exclude (-) verdict:
- 10.0.0.0/8 - exclude private network addresses from being split-tunnelled (e.g., keep LAN traffic on the VPN).+ updates.example.com - when used with a per-app override, force a specific domain through the split tunnel even if a global exclude rule would otherwise skip it.Rules are evaluated top-to-bottom; the first match wins. If no rule matches, the connection is split-tunnelled (because "Use Split Tunnel" is enabled).
Tip: Because this setting is stackable, a global rule (e.g. exclude a domain) can be overridden by a per-app rule (e.g. allow that same domain for a specific app). Per-app rules are evaluated first.
Portmaster's SPN (Safing Privacy Network) takes precedence over Split Tunnel. If SPN is enabled globally, a connection that would otherwise be split-tunnelled will instead be routed through SPN.
To use Split Tunnel alongside SPN:
Split tunneling is most commonly used alongside a VPN. The typical flow:
- rule), it is not split-tunnelled and falls back to normal OS routing - which means it goes through the VPN, unless another rule (such as a block or SPN) applies first.Goal: You have a VPN running for all traffic, but you want your streaming app to use your direct ISP connection (e.g. to access region-locked local content).
Configuration:
That's it. The streaming app now exits through your physical connection while everything else stays in the VPN.
This is a more complex setup combining SPN, a VPN, and Split Tunnel simultaneously.
Precondition: A VPN is active and set as the system's default route - all traffic goes through the VPN unless overridden.
Desired result:
| App / Destination | Routing |
|---|---|
| App1 | SPN |
| App2 | VPN (default) |
| App3 - general traffic | Physical interface (direct ISP) |
App3 → domain1.example.com |
VPN |
App3 → domain2.example.com |
SPN |
How to configure this in Portmaster:
Enable the Split Tunnel Module in global settings.
App1 profile:
App2 profile:
App3 profile:
domain1.example.com:- domain1.example.com
domain2.example.com:+ domain2.example.com
- *
domain2.example.com goes through SPN. All other App3 traffic is unaffected by SPN and uses Split Tunnel → physical interface.How traffic is resolved for App3:
| Destination | SPN rule | ST rule | Result |
|---|---|---|---|
domain2.example.com |
✓ permitted | (overridden by SPN) | SPN |
domain1.example.com |
✗ denied | excluded (-) |
VPN (OS default) |
| Everything else | ✗ denied | ✓ active | Physical interface |
If split tunneling does not behave as expected, work through this checklist:
splittun/enable).| Limitation | Details |
|---|---|
| Protocols | Only TCP and UDP are supported. ICMP and other protocols are unaffected by split tunnel rules. |
| Inbound connections | Only outgoing connections can be split-tunnelled. Inbound connections are ignored. |
| Localhost traffic | Connections to/from 127.0.0.1 or ::1 are never split-tunnelled. |
| Interface availability | If the configured interface disappears (VPN disconnects, Wi-Fi drops), new connections will fail rather than fall back automatically. |
| Auto-detection reliability | Automatic interface detection ("empty" setting) tries to pick the best physical interface, but may choose incorrectly in complex network setups (e.g., multiple VPNs, Docker bridges). Manual configuration is recommended for production use. |
| No DNS bypass | DNS queries are handled separately by Portmaster's nameserver. Split Tunnel rules do not affect DNS resolution; DNS still goes through the normal Portmaster flow. |
| Max concurrent sessions | The internal proxy has a configurable session limit. Under very high connection loads, new connections may be rejected if the limit is reached. |
| Does not fix VPN compatibility issues | Split Tunnel only controls which network interface a connection is routed through. It does not resolve any compatibility problems between Portmaster and third-party VPN clients (e.g. driver conflicts, DNS leaks caused by the VPN app, kill-switch interference). If a VPN app had issues working alongside Portmaster before, Split Tunnel will not change that. |
Is split tunneling only for advanced users?
No. Basic setups are straightforward - enable the module, turn it on for one app, and you're done. Advanced rule tuning (per-destination rules, stacking global and per-app rules) is optional and only needed for complex scenarios.
Does split tunneling expose my real IP?
Yes - intentionally. The whole point is to route certain traffic outside the VPN/privacy layer. Only enable it for apps and destinations where that trade-off is acceptable.
Can I split-tunnel only specific domains or IPs for an app, not all of its traffic?
Yes. Use the Split Tunnel Rules setting to allow (+) or exclude (-) specific endpoints. Leave the rest to the default behaviour set by "Use Split Tunnel".
What happens if the module is disabled while apps are running?
Portmaster will gracefully shut down the internal proxies and clear any pending connection registrations. Existing proxied connections will be closed; future connections from those apps will be routed normally (without split tunneling).
Why is my connection dropped instead of falling back to the VPN?
Portmaster deliberately fails the connection when the requested interface is unavailable. Silently falling back would defeat the purpose of split tunneling and could inadvertently route traffic through the VPN when you expected it to bypass it (or vice versa).
Does this work on all platforms?
Yes, but with a difference in how interface selection is enforced. On Linux, Portmaster can bind the outgoing connection directly to a named network device, which is the most reliable method. On Windows, the binding is done by IP address instead, so the OS routing table has the final say on which physical interface is used. For most setups this still produces the correct result, but in complex multi-interface environments Linux provides stronger guarantees.
Does split tunneling work when no VPN is active?
Yes. Split Tunnel is not tied to VPN usage. It works whenever you want to direct an app's traffic through a specific interface - whether that is a secondary Ethernet adapter, a mobile hotspot, or any other interface on the device. The VPN is just the most common scenario.
How can I verify that split tunneling is working?
Open Portmaster's Network Monitor (or the connection details for the app). Split-tunnelled connections will show the interface and IP address they were routed through. If the connection shows the expected physical interface instead of the VPN adapter, split tunneling is working correctly.