Last updated: March 15, 2026

Split tunneling routes only work applications through your corporate VPN while personal browsing, streaming, and video calls use your regular internet connection directly, improving bandwidth and reducing latency while maintaining secure access to corporate resources. Configure split tunneling at the application level using your VPN client’s app list, or at the routing level using firewall rules and policy routing on Linux. This guide walks through setting up split tunneling for work-only applications on macOS, Windows, and Linux, plus discusses security implications and best practices for hybrid work environments.

Table of Contents

Why Split Tunneling Matters

When you use a full VPN tunnel, all your network traffic routes through the VPN server. This means your personal browsing, video calls with family, and streaming services all travel through the corporate VPN infrastructure. The consequences include:

Split tunneling solves these problems by letting you choose which applications use the VPN tunnel and which connect directly to the internet.

Prerequisites

Before you begin, make sure you have the following ready:

Step 1 - Understand Split Tunneling Basics

Split tunneling operates at the application or routing level. You have several approaches:

Application-Based Split Tunneling

Some VPN clients let you select which applications route through the VPN. This is the simplest approach for most users.

Route-Based Split Tunneling

Advanced users can configure routing tables to direct specific IP ranges through the VPN while everything else uses the default gateway.

Domain-Based Split Tunneling

Corporate environments often use domain-based rules to route traffic based on domain names or internal hostnames.

Step 2 - Set Up Split Tunneling

WireGuard Configuration

WireGuard uses a simple configuration file. To route only specific applications, you configure the AllowedIPs setting:

[Interface]
PrivateKey = your-private-key
Address = 10.0.0.2/32
DNS = 10.0.0.1

[Peer]
PublicKey = server-public-key
Endpoint = vpn.company.com:51820
AllowedIPs = 10.0.0.0/24, 192.168.100.0/24

The AllowedIPs setting determines which IP ranges route through the VPN. In this example, only traffic to the corporate network (10.0.0.0/24 and 192.168.100.0/24) goes through the VPN. Everything else uses your regular connection.

To explicitly exclude ranges, use the catch-all approach with specific exclusions:

AllowedIPs = 0.0.0.0/0

Then use routing policy database (RPDB) rules or iptables to exclude specific destinations.

OpenVPN Configuration

OpenVPN supports split tunneling through the route and iroute directives. Add these to your client configuration:

Route only specific subnets through VPN
route 10.0.0.0 255.255.255.0
route 192.168.100.0 255.255.255.0

Prevent routing all traffic through VPN
redirect-gateway def1 bypass-dhcp

The redirect-gateway def1 bypass-dhcp option ensures your default gateway remains unchanged, giving you direct internet access while VPN routes handle corporate subnets.

Windows Built-in VPN Split Tunneling

Windows 10 and 11 support split tunneling through the Settings app or PowerShell:

Create VPN connection with split tunneling
Add-VpnConnection -Name "Work VPN" `
    -ServerAddress "vpn.company.com" `
    -TunnelType "Automatic" `
    -AuthenticationMethod MSChapv2 `
    -RememberCredential -SplitTunneling $True

Configure routing for corporate network only
$route = New-NetRoute -DestinationPrefix "10.0.0.0/24" `
    -InterfaceAlias "Work VPN" `
    -NextHop "10.0.0.1"

Step 3 - Configure Application-Specific Routing

For precise control over which applications use the VPN, you can use network namespaces on Linux or application-specific firewall rules.

Linux - VPN Exclusively for Specific Apps

Create a dedicated network namespace for work applications:

Create network namespace
sudo ip netns add work-vpn

Set up VPN interface in namespace (WireGuard example)
sudo wg show | sudo ip netns exec work-vpn wg setconf wg0 /etc/wireguard/wg0.conf

Run application in namespace
sudo ip netns exec work-vpn firefox -P work-profile

This approach isolates work applications in their own network stack with the VPN, while all other applications use your regular connection.

macOS: Per-Application VPN with Third-Party Tools

macOS doesn’t natively support application-based split tunneling. Tools like Surge or Outline Manager provide application-level routing:

Example Surge configuration for split tunneling
[Proxy]
work = ss://your-server-config

[Rule]
PROCESS-NAME, Slack, work
PROCESS-NAME, Microsoft Teams, work
PROCESS-NAME, Outlook, work
DOMAIN-SUFFIX, company.com, work
DOMAIN-SUFFIX, internal.corp, work
GEOIP, CN, work
FINAL, DIRECT

Windows - Force Application Through VPN

Use PowerShell to create a VPN interface and route specific application traffic:

Create a persistent route for work network through VPN
New-NetRoute -DestinationPrefix "10.0.0.0/24" `
    -InterfaceAlias "Work VPN" `
    -NextHop "10.0.0.1" `
    -RouteMetric 1

Use Windows Filtering Platform to direct app traffic
This requires creating a filter with specific application ID

Step 4 - Common Split Tunneling Scenarios

Remote Work Setup

A typical remote worker needs access to:

Everything else, personal email, streaming services, social media, should bypass the VPN.

Example WireGuard configuration:

[Peer]
PublicKey = server-public-key
AllowedIPs = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
PersistentKeepalive = 25

Developer Configuration

Developers often need access to:

Route only specific corporate ranges
route 10.0.0.0 255.255.0.0
route 172.16.0.0 255.240.0.0

Exclude common cloud provider ranges from VPN
These typically go direct for better performance

Accessing Specific Services Only

For users who only need access to particular resources:

[Peer]
PublicKey = server-public-key
AllowedIPs = vpn.company.com/32, gitlab.internal/32

This routes only traffic to the specified hostname (via DNS resolution) and IP through the VPN.

Troubleshooting Split Tunneling

Traffic Not Routing Correctly

Verify your routing table:

Linux
ip route show

Windows
route print

macOS
netstat -rn

Check that your corporate network routes use the VPN interface while default traffic uses your regular gateway.

DNS Leaks

When using split tunneling, DNS requests might leak to your ISP. Force DNS through the VPN tunnel:

Linux - force DNS through VPN
sudo resolvectl dns wg0 10.0.0.1
sudo resolvectl routing-domain wg0 private

Verify
resolvectl query vpn.company.com

Application Connectivity Issues

Some applications hardcode server addresses. Use tcpdump or Wireshark to verify traffic flow:

Capture traffic on VPN interface
sudo tcpdump -i wg0 -n

Capture traffic on regular interface
sudo tcpdump -i eth0 -n

Compare the captured traffic to ensure corporate IP ranges go through the VPN interface.

Security Considerations

Split tunneling introduces security considerations:

Data Exfiltration Risk

With split tunneling, malicious software on your machine could potentially access both corporate resources and the internet simultaneously. Mitigate this with:

Split Tunnel Detection

Some organizations detect split tunneling through:

Ensure your configuration aligns with corporate policy.

Always-On VPN Considerations

For high-security environments, consider combining split tunneling with always-on VPN:

Linux - kill switch using iptables
sudo iptables -A OUTPUT ! -o wg0 -j DROP
sudo ip6tables -A OUTPUT ! -o wg0 -j DROP

This prevents any traffic when the VPN is down.

Step 5 - Measuring Split Tunneling Effectiveness

Test your configuration to ensure it’s working as expected:

Check public IP (should show your ISP IP, not VPN)
curl ifconfig.me

Check corporate network routing (should show VPN endpoint)
ip route get 10.0.0.1

Verify DNS resolution
nslookup gitlab.internal

Best Practices

  1. Start simple: Use your VPN client’s built-in split tunneling before custom configurations
  2. Document your setup: Note which apps and domains route through VPN
  3. Test regularly: Verify split tunneling after system updates
  4. Monitor bandwidth: Ensure personal activities don’t consume corporate VPN resources
  5. Coordinate with IT: Ensure compliance with organizational security policies

Frequently Asked Questions

How long does it take to work apps only guide?

For a straightforward setup, expect 30 minutes to 2 hours depending on your familiarity with the tools involved. Complex configurations with custom requirements may take longer. Having your credentials and environment ready before starting saves significant time.

What are the most common mistakes to avoid?

The most frequent issues are skipping prerequisite steps, using outdated package versions, and not reading error messages carefully. Follow the steps in order, verify each one works before moving on, and check the official documentation if something behaves unexpectedly.

Do I need prior experience to follow this guide?

Basic familiarity with the relevant tools and command line is helpful but not strictly required. Each step is explained with context. If you get stuck, the official documentation for each tool covers fundamentals that may fill in knowledge gaps.

Is this approach secure enough for production?

The patterns shown here follow standard practices, but production deployments need additional hardening. Add rate limiting, input validation, proper secret management, and monitoring before going live. Consider a security review if your application handles sensitive user data.

Where can I get help if I run into issues?

Start with the official documentation for each tool mentioned. Stack Overflow and GitHub Issues are good next steps for specific error messages. Community forums and Discord servers for the relevant tools often have active members who can help with setup problems.

Related Articles