Windows VPN Taking All Your Traffic? Remove Its Default Route

You connect to the office VPN and every page in the browser starts going through that network: the file server is fast, everything else is slow, filtered or gone. The client is not misbehaving; the profile asked for a full tunnel. The switch that stops it is one checkbox in a dialog the modern Settings app does not show, and the gateway gets a say again at every connect. This walkthrough follows the order the Windows interface actually presents, then covers the checks that still fail after the route table looks correct.

Start in the adapter properties, not in Settings

The Settings app lists the profile under Network & Internet, then VPN, but it exposes only general options. The default-gateway decision lives on the adapter. Open the classic adapter list with Win+R and ncpa.cpl, right-click the VPN connection, choose Properties, select Internet Protocol Version 4, choose Properties again, then Advanced. Clear Use default gateway on remote network and confirm your way out of all three dialogs.

Reconnect before testing, because the checkbox is applied when the tunnel is established and an existing session keeps the table it built. If the adapter is missing while the client is disconnected, connect once and reopen the window. A vendor client that installs a TAP or Wintun adapter without an IPv4 properties page does not have this dialog at all; for those, the same decision is a split-tunnel option inside the client's own settings, and the adapter checkbox is the wrong place to look.

The same change from PowerShell

For a profile created in the Windows VPN store, the setting is scriptable, which is what you want if the machine is rebuilt often:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

That cmdlet only reaches profiles in that store. A connection added by a third-party client will not appear, and the command fails with a name error that reads like a typo. Also note what the switch does not do: it stops the client from installing a default route, but it does not remove routes the gateway pushes at connect time, so the next section is still required on many networks.

When the gateway pushes the default back

Read the table first. Two default entries with different metrics mean the profile change worked and the pushed route replaced it anyway:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Delete the default that belongs to the tunnel and keep the physical one. Use the interface index from the third command, not the adapter alias, because scripts that pass an alias break as soon as the display name changes:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

The deletion takes the office with it, so add the corporate prefixes back through the tunnel gateway. This is the line people skip, and it is the reason "the VPN stopped working" follows a successful split-tunnel change:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

None of this survives a reconnect, which is honest behaviour rather than a bug: the adapter is rebuilt and the client re-applies what the profile and the gateway agreed on. If the default reappears every time, the gateway is configured to refuse split tunnelling and will keep pushing it, or drop the session. That is the network operator's policy, and the request belongs there rather than in a local script that fights it once per connect.

Recheck DNS, IPv6 and the metrics after one reconnect

Removing an IPv4 default route proves nothing about the other family or about name resolution. A tunnel can carry IPv6 while the IPv4 default stays local, and a pushed resolver list can keep internal names working while the queries that use it travel a different path. Check all three before you call it done:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

If the state reverts on every connect, move the commands into a per-connect action instead of editing the table by hand: a scheduled task triggered on the connection event, or the client's own split-tunnel setting where it has one. Keep the interface index in a variable and look it up at run time, since it can change when adapters are added or removed.

Decide what you gave up

Local internet traffic is no longer inspected or filtered by the office, and anything published only through the tunnel now needs its own route. Some organisations treat split tunnelling as a policy violation, so confirm that before changing a managed device; a pushed default is sometimes the enforcement mechanism rather than an accident. The Set-VpnConnection documentation lists the split-tunnelling parameter and the profile types it applies to.

Then verify in a fixed order: who owns the default route, ordinary browsing, one corporate host by address, one internal name, and the same four after a single reconnect. If browsing works and the corporate host fails, the prefix route is missing rather than the default you removed, which is a much cheaper thing to fix than rebuilding the profile.