Fix VPN Split Tunneling Ignoring Routes After Sleep on Windows 11

Quick fix: After sleep, Windows’ route table partially rebuilds — sometimes losing the VPN split-tunnel routes added via route add. Re-establish the VPN connection, or set up a Task Scheduler task triggered by “On wake” that re-runs your routing script automatically.

Your VPN client uses split tunneling: only specific subnets go through the VPN, everything else routes normally. Before sleep, the configuration was right — route print showed the VPN routes for your corporate subnet, and the rest of your traffic went direct. After waking from sleep, those VPN routes are gone. Traffic that should go through the VPN now tries to reach the corporate subnet directly and fails.

Why split-tunnel routes disappear

When Windows sleeps, the network adapter often disassociates — especially on laptops where Wi-Fi is disabled to save power. On wake, the adapter reconnects and Windows rebuilds the routing table from base DHCP/static configuration. VPN-injected routes that were added via route add after the VPN tunnel came up aren’t in the base config; they’re lost. The VPN tunnel itself usually reconnects, but the routes that pointed traffic into it don’t.

Most VPN clients handle this with their own watchdog: detect adapter state changes, re-add routes. The issue surfaces with VPNs that don’t (or with manual route add setups).

Method 1: Re-establish the VPN to repopulate routes

1. Disconnect the VPN from the client UI.
2. Reconnect.
3. Open elevated Command Prompt and run route print. Confirm your VPN subnet routes are back.
4. Test by pinging an internal-only IP — should succeed.

This is the quick fix every time. The VPN client re-runs its post-connect script that adds the routes. Many users do this routinely after every wake; the next methods automate it.

Method 2: Set up a scheduled task on wake-from-sleep

Automate the re-route fix by triggering a script on system wake.

1. Create your route script C:\Scripts\vpn-routes.cmd:
   
   @echo off

route add 10.0.0.0 mask 255.255.0.0 10.99.99.1 if X

route add 172.16.0.0 mask 255.240.0.0 10.99.99.1 if X
   
   (Replace 10.0.0.0, 10.99.99.1 (VPN gateway), and X (interface index) with your values. Get the interface index from route print.)
2. Open Task Scheduler. Create a new task.
3. On Triggers, click New. Set begin task to On an event. Log: System; Source: Power-Troubleshooter; Event ID: 1. This fires when the system resumes from sleep.
4. On Actions, click New. Action: Start a program. Program: C:\Scripts\vpn-routes.cmd.
5. On General, check Run with highest privileges.
6. Save and test by sleeping and waking the laptop.

The script runs immediately after wake. If your VPN auto-reconnects, the routes are added on top of that — route table looks identical to before sleep within seconds.

Method 3: Configure the VPN client’s reconnect behavior

Different VPN clients handle wake differently. Optimize the one you use.

1. OpenVPN GUI: edit your .ovpn config and add persist-tun, persist-key, and resolv-retry infinite. Set --script-security 2 and use the --up hook to add routes — this runs on every reconnect including post-sleep.
2. WireGuard: routes added via AllowedIPs persist via the interface lifecycle — usually no extra config needed. If routes still disappear, set the interface to auto-reconnect on wake (right-click the tunnel in WireGuard UI → Set Activate on Demand).
3. Cisco AnyConnect: enable the “Automatic VPN” profile setting and configure trusted-network-detection so the client re-establishes immediately.
4. Built-in Windows VPN: set Auto-reconnect via PowerShell: Set-VpnConnection -Name “YourVPN” -RememberCredential $True -AutoTriggerEnabled $True.

The right client-side config eliminates the manual step. Set it up once and forget about it.

How to verify the fix worked

• Run route print before sleep. Note your VPN routes.
• Sleep for 5 minutes, then wake.
• Wait 10 seconds for the reconnect to complete.
• Run route print again. Same VPN routes present.
• Ping an internal-only IP. Succeeds.
• Repeat with a longer sleep (30+ minutes) and verify routes still come back.

If none of these work

If routes don’t re-add even with Method 2 in place, the Task Scheduler trigger may not be firing — check Task Scheduler → History tab for your task. If no history events appear, the trigger isn’t matching the actual event. Try a broader trigger like “At log on” instead, combined with a delay. For corporate VPN setups where the IT department’s VPN client should handle this automatically, escalate to IT — they may have a misconfigured profile. For OpenVPN specifically, check the log file for “route add” errors that suggest the route hasn’t been added because the interface isn’t ready yet — add a sleep delay before route commands in the --up script.

Bottom line: Split-tunnel routes disappear because the route table rebuilds on wake. Either re-establish the VPN manually, automate it via Task Scheduler on the wake event, or configure the VPN client to handle it. The Task Scheduler approach is the most universal fix.