Why Your Windows VPN Route Table Shows 0.0.0.0/1 and 128.0.0.0/1

Connect to a Windows VPN and open the route table, and two entries stand out: 0.0.0.0/1 and 128.0.0.0/1. They are not a typo and they do not replace the default route. Whether they appear depends on one profile option, and the pair is how a full tunnel is built rather than a split-tunnel feature. Read the option, the prefix and the interface together before changing a single line.

What the Default-Gateway Option Installs

The profile option that sends everything through the tunnel works by adding those two prefixes. Clear the option and they disappear, leaving a route that covers only the subnet handed to the tunnel adapter. The checkbox controls the pair; it does not rewrite the single default route. That is why the table after unticking looks like a partial rewrite instead of a deletion.

0.0.0.0/1 covers the lower half of the IPv4 space and 128.0.0.0/1 covers the upper half, so together they cover every unicast address. Each is more specific than a 0.0.0.0/0 default, which means longest-prefix matching sends ordinary traffic into the tunnel while the physical default route stays where it was. Keeping that default is not cosmetic: the packets that wrap the encrypted payload are addressed to the server's public address and have to leave through the physical adapter. Replace the default instead of splitting it, and the tunnel's own transport tries to enter the tunnel, which is a loop rather than a connection.

A literal 0.0.0.0/0 pointing at the VPN adapter is therefore worth stopping for. The native client does not normally write that, so a manual route or another client's configuration has changed the table behind your back. Find it before debugging anything downstream.

Teardown Is Cheaper Than Saving a Gateway

Teardown is the practical argument for two entries over one. The client owns exactly two routes while connected and deletes them on disconnect, leaving whatever the physical adapter holds at that moment. A client that had replaced the single default would have to remember the previous gateway, and after a DHCP lease change it could restore one that no longer exists. Two owned entries carry no such state.

Other clients reach the same design. An OpenVPN profile with redirect-gateway def1 installs those two prefixes instead of deleting the default, and the Windows client follows the pattern for the same routing reason.

This is also why a table can look like a full tunnel when you expected a split. The pair is how the full tunnel is constructed, not evidence of a split-tunnel mistake. If the profile is set to use the remote gateway, everything is routed, whatever one local application still manages to reach.

Longest Prefix Wins Before Any Metric

Prefix length decides the lookup before any other field. Metric only breaks ties between routes with an identical prefix, so a /1 entry beats a /0 default even when its metric is worse. Interface binding decides what is left when two routes share a prefix and Windows has to choose which adapter sends the packet.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

A split-tunnel table holds the physical default, the two half-defaults, the route for the tunnel subnet and any office prefix you added. The physical default may sit at a lower or a higher metric depending on the client and the profile, and while the /1 pair exists that difference changes nothing. It changes everything the moment the pair is removed, which is when a stale gateway or a wrong interface surfaces. Read the whole table rather than the one line you expected to change.

Choose One Owner for the Office Prefix

For a split tunnel, name only the prefix that has to use the VPN, and pick one way to own it. Pointing the route at the assigned tunnel address works until that address changes, while binding to the interface survives the address but breaks when the index is reassigned after the profile is rebuilt. The profile-bound cmdlet avoids both problems, at the cost of needing the profile.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

The cmdlet binds the prefix to the named profile, so the route appears with the connection and leaves with it, which is what a managed laptop wants. A persistent route outlives reboots and outlives the profile that motivated it, which is how a retired VPN leaves entries behind for years. Pick one method per prefix and note the choice, because a persistent route plus a profile route for the same prefix produce duplicates that are painful to untangle during teardown. Whichever you pick, the ownership should be visible in the ticket and not only on the machine.

Ownership is the question this section answers, not syntax. Two owners for one prefix is the failure mode worth avoiding.

Verify With a Destination, Not a Website

Test the destination that has to cross the tunnel, not a website that reports an exit address. Find-NetRoute returns the selected route and the source address, so you can see whether the office prefix or the physical default won, and then you open the share itself.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

An exit-address site is a weak check, because DNS, IPv6 and a browser proxy can each send that request down a different path. IPv4 and IPv6 also have separate settings in the same dialog, and clearing one box leaves the other family untouched, so a dual-stack machine can carry IPv6 through the tunnel while IPv4 follows the split route. Check both families before calling the profile split. If the route is right and the service still fails, the remaining layer is filtering rather than routing.

A client-managed firewall can block the office subnet with a perfect route table in place. That policy belongs to whoever pushed the profile, not to the person editing routes.