Split Tunnel on Windows: The Gateway Box and the Missing Prefix

The tunnel reports connected and the wiki still loads. Then a download stalls and the share on the shelf stops answering. The tunnel did its job, and the profile simply claimed every destination.

Windows treats a VPN connection as a route decision. Until that decision is narrowed, the machine behaves as if it had moved to the office.

Why a Working Tunnel Feels Like an Outage

A profile allowed to use the remote gateway installs a default route through the tunnel. Every destination that is not on the local link then leaves through the office firewall. Local shares stop answering because their traffic now travels to another continent and back. Nothing in the client status reflects that.

The symptoms are confusing on purpose. Name resolution may still work while the share times out, or the reverse. A user reports the VPN as broken, the client reports itself as fine, and both statements are accurate.

The Checkbox Hiding in the IPv4 Dialog

The setting sits several dialogs deep. Open ncpa.cpl, right-click the connection, then IPv4 properties, then Advanced, and clear the option that lets the connection become the remote default gateway. That one box decides whether the profile is a full tunnel. Everything else in the profile still applies.

Compare route print -4 before and after the reconnect. The 0.0.0.0 entry that used to point at the tunnel should be gone, and the corporate prefixes should still be there.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Changing the interface metric is not a substitute. A metric only decides between two competing defaults, and a client that reinstalls its own default on connect wins that contest whatever number is set.

The Prefix Nobody Listed

Split tunnelling exposes exactly the prefixes recorded in the profile. An office subnet added after the profile was written stays unreachable while the tunnel is perfectly healthy. The report then arrives as one broken server rather than a broken VPN.

A hand-added route covers the gap until the gateway address changes. Recording the prefix in the connection is sturdier, because the prefix then follows the connection instead of a guessed address.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Read the stored list and the live table together. A stored prefix can exist while the table never receives it, which happens when a management agent filters routes after the connection comes up. The reverse occurs too, with a registry route pointing at an adapter that is down. Neither view alone tells the whole story.

Proving the Result After a Reboot

Trace in both directions and resolve by name. A public trace should leave through the ISP, an internal trace should enter the tunnel, and an internal host should answer by name rather than only by address.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Repeat after a disconnect, a reconnect and one reboot. A prefix that survives a manual reconnect and disappears after a restart was never stored in the profile.

Keep the printer and the NAS in the test as well, because a split tunnel that cuts off the devices beside the laptop has solved one problem by creating a smaller and more irritating one. Microsoft's Add-VpnConnectionRoute reference is the place to check parameter spelling against your module version.