VPN Split Tunnel Broken? Fix DNS & Routes Fast

1. DNS Leak: Your VPN Is Still Sending Queries to the Corporate DNS

This is the one that trips up most people — and it was my own headache for a solid week in 2019. You set up split tunnel, you can ping your local printer just fine, but every web request takes 10 seconds to load. The culprit? Your VPN client is still pushing a corporate DNS server that's only reachable through the tunnel.

When the DNS server is inside the VPN tunnel, your machine sends the query through the tunnel, waits for a timeout, then falls back to the local resolver. That's the delay. And in some setups — especially with Cisco AnyConnect or OpenVPN — the VPN client doesn't update the DNS search list properly.

How to Spot It

Open a command prompt or terminal and run:

# Windows
ipconfig /all | findstr "DNS"

# macOS
scutil --dns | grep 'nameserver'

If you see a corporate DNS server IP (like 10.x.x.x or 172.x.x.x) on your active interface, that's your problem. The split tunnel's not routing that DNS traffic out the local interface.

The Fix

Option 1: Override DNS in your VPN client

In OpenVPN, add these lines to your client config:

dhcp-option DNS 8.8.8.8
# Or use your local router's DNS, like 192.168.1.1

For Cisco AnyConnect, you can't change DNS per-profile easily. Instead, disable the VPN's DNS push on Windows by setting the adapter's DNS manually:

1. Go to Network Connections (ncpa.cpl).
2. Right-click your VPN adapter, choose Properties.
3. Double-click Internet Protocol Version 4 (TCP/IPv4).
4. Click Advanced, then the DNS tab.
5. Uncheck "Register this connection's addresses in DNS".
6. Set a static DNS like 8.8.8.8 or your local router.

Option 2: Use Windows Registry to force DNS over the local interface

This one's hacky but works when the VPN client keeps overwriting your settings. Open regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{VPN-Adapter-GUID}

Set NameServer to your local DNS (e.g., 8.8.8.8). Then set DhcpNameServer to the same value. Reconnect VPN. I've had to do this for a client's Palo Alto GlobalProtect setup that refused to honor the split tunnel DNS policy.

2. Missing Routes: Your Local Network Is Invisible Behind the Tunnel

You've got split tunnel turned on, but you can't reach your local NAS at 192.168.1.50. This happens because the VPN pushed a default route (0.0.0.0/0) even with split tunnel enabled — a common misconfiguration on the server side.

Or worse, your VPN client flushes the local routing table on connect. I've seen this with older versions of the Pulse Secure client (pre-9.0). It literally deleted the route to the local subnet every time you connected.

How to Check

While connected to VPN, run:

# Windows
route print -4

# macOS / Linux
netstat -rn

Look for your local subnet (e.g., 192.168.1.0/24). If the route is missing, that's the problem.

The Fix

Add a persistent route

On Windows, add a route that uses your local gateway:

route ADD 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 10 -p

The -p flag makes it persistent across reboots. Replace the subnet and gateway with your own. For macOS, use:

sudo route -n add -net 192.168.1.0/24 192.168.1.1

But you'll need to add it to a script that runs on VPN connect (use /etc/ppp/ip-up on macOS or a launchd plist).

If your VPN client is overriding routes on connect, create a batch script that runs after the VPN connects. For Windows, write a .bat file:

@echo off
route ADD 192.168.1.0 MASK 255.255.255.0 192.168.1.1

Then schedule it in Task Scheduler to trigger on event ID 20225 (VPN connection) for the RasClient source. This is janky but bulletproof.

3. Firewall Rules Blocking Local Traffic Over the Tunnel

This one's sneaky. Your routes are correct, DNS is working, but you can't SSH into your local server when the VPN is up. The culprit is the VPN client's firewall — many corporate VPNs (especially VPNs like Cisco AnyConnect or FortiClient) install a firewall filter that blocks non-VPN traffic by default.

I watched a sysadmin spend two hours pinging his local NAS before realizing the AnyConnect firewall was dropping all traffic that wasn't destined for the corporate network.

How to Spot It

Disable the VPN client's firewall (if you can temporarily). On AnyConnect, right-click the tray icon, go to Advanced -> Troubleshooting -> Firewall Status. If it's in "Block All" mode, that's your issue. On FortiClient, check the Firewall Policy tab under the VPN profile.

You can also do a quick test: while disconnected from VPN, check if local traffic works. Then connect, and try again. If it fails, it's firewall, not routing.

The Fix

For AnyConnect: Open the VPN profile (it's XML, usually in C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\) and look for <BlockLocalTraffic>false</BlockLocalTraffic>. If it's set to true, change it to false. You'll need admin rights to edit this. Restart the VPN.

For FortiClient: Edit your VPN connection in the GUI. Under Security -> AntiVirus & Firewall, set the firewall policy to "Outbound Access Control" with a rule that allows your local subnet. Or just disable the built-in firewall entirely — it's redundant if you already have Windows Defender Firewall.

For OpenVPN: Add this to your config to bypass the VPN firewall for local traffic:

route 192.168.1.0 255.255.255.0 net_gateway

Also check if your OpenVPN config has block-outside-dns — that's a common cause of DNS leaks that look like firewall issues.

Quick-Reference Summary Table

If none of these fix it, your VPN server might be pushing a bad configuration. Check with your IT team to see if they've enabled split tunnel on the server side at all — some admins forget to toggle it on. I've seen that happen more than once. Good luck — and keep a copy of your routing table handy in case you need to reset it.