Split-Tunnel VPN Routing Misconfiguration

Step 1: Inspect the Routing Table

# Linux
ip route show
# or for all routing tables:
ip route show table all

# macOS
netstat -rn
# or:
route -n get 10.10.0.0/24  # Test a specific corporate subnet

# Windows (PowerShell)
Get-NetRoute | Sort-Object RouteMetric | Format-Table -AutoSize
# or:
route print

Step 2: Trace a Specific Destination

# Trace the path to an internal resource
traceroute 10.10.5.100   # Should go through tun0/wg0
traceroute 8.8.8.8       # Should go through eth0/en0 (physical NIC)

# On Linux, verify which interface handles a route:
ip route get 10.10.5.100
# Output should show: via 10.8.0.1 dev wg0

Step 3: Review WireGuard AllowedIPs (Source of Truth for Split Tunnel)

sudo wg show
# AllowedIPs field for the server peer defines what goes into the tunnel
# "0.0.0.0/0" = full tunnel (all traffic)
# "10.10.0.0/16" = only corporate subnet goes through VPN

Step 4: Check OpenVPN Routes (if using OpenVPN)

# OpenVPN pushes routes into the kernel on connect
# Check what was pushed:
journalctl -u openvpn@client | grep "route"
# or review the pushed route statements:
sudo cat /etc/openvpn/client.conf | grep route

# Verify active VPN routes:
ip route show | grep tun0

Step 5: Identify Route Conflicts

# Check for conflicting routes (same prefix, multiple next hops)
ip route show | sort
# If 10.10.0.0/24 appears twice with different gateways, the OS picks by metric
ip route show metric  # Lower metric = preferred

Fix 1: Add Missing Subnets to AllowedIPs (WireGuard)

Edit the client configuration and list all corporate subnets explicitly:

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.com:51820
# Split tunnel: route only corporate ranges through VPN
AllowedIPs = 10.10.0.0/16, 172.16.0.0/12, 192.168.100.0/24

Use the WireGuard AllowedIPs calculator at https://www.wireguardconfig.com/allowedips to generate the correct CIDR complement for full-tunnel exclusions.

Fix 2: Add Routes Manually (OpenVPN / OS-level)

# Linux: add a missing corporate route through the VPN gateway
sudo ip route add 10.10.5.0/24 via 10.8.0.1 dev tun0

# Make persistent (systemd network or /etc/network/interfaces):
# post-up ip route add 10.10.5.0/24 via 10.8.0.1 dev tun0

# macOS:
sudo route add -net 10.10.5.0/24 10.8.0.1

# Windows:
route add 10.10.5.0 MASK 255.255.255.0 10.8.0.1

Fix 3: Flush Route Cache and Reconnect

# Linux: flush route cache
sudo ip route flush cache

# Bring the WireGuard interface down and up
sudo wg-quick down wg0
sudo wg-quick up wg0

# Verify routes were correctly applied
ip route show | grep wg0

Fix 4: Resolve Overlapping Subnets

If the corporate range overlaps with your local LAN (e.g., both use 192.168.1.0/24), change the local LAN subnet on your home router or work with the VPN admin to assign a non-conflicting internal range.

• Document all corporate subnets and validate them against the AllowedIPs list before rolling out VPN profiles
• Use a post-connect script that verifies key routes exist and alerts the user if any are missing
• Standardise on non-RFC1918-overlapping corporate address ranges (e.g., 10.20.0.0/14) to avoid LAN conflicts
• Test split-tunnel routing from a guest Wi-Fi network immediately after configuration changes
• Review routing tables after every OS update — some updates reset or modify route tables