Hope this is a suitable place to ask. I have a VPN connection set up on my home Windows 10 PC which lets me join the network at my office. At some point I noticed my internet connection seemed very slow and after a little bit of investigation discovered that Windows was routing all non-local traffic through the VPN.

I learned about the 'Use default gateway on remote network' checkbox in the IPv4 properties on the VPN connection, and have unchecked it. This solves the problem but only temporarily. After 'a while' (don't know exactly when it happens, I usually notice it within a couple of days) my internet connection feels slow again and sure enough all traffic is being routed through the VPN.

Using route print whilst the traffic is going through the VPN shows:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
         On-link     26   4251         On-link   4556         On-link   4556         On-link   4556         On-link   4506         On-link   4506         On-link   4506         On-link    281         On-link   4556         On-link   4506         On-link     26         On-link   4556         On-link   4506         On-link    281
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric

My home PC is (statically assigned), with being my home router. The network I am joining through the VPN is, given an IP address by DHCP.

I can see it's added a route to use the VPN and given it the lowest metric. I don't know what 'On-link' means in this context.

The checkbox is still unchecked. If I disconnect and then reconnect the VPN connection, everything is fixed:

IPv4 Route Table
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
    281     26         On-link    331         On-link    331         On-link    331         On-link    281         On-link    281         On-link    281     26         On-link    281         On-link    331         On-link    281         On-link    281         On-link    331         On-link    281         On-link    281
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric

Only traffic for is sent via the VPN, which is what I want.

Does anyone know what could cause Windows to keep suddenly deciding to ignore the 'Don't use remote gateway...' option and adding a route anyway?

Is there some kind of 'negative route' I can add permanently which effectively blocks any unwanted traffic going to the VPN?

Edit to add: I also tried manually setting the metric very high in the same page of the VPN IPv4 properties, but this seems to have no effect and is not reflected in the output of route print.

Edit to add: I've also noticed another strange behaviour regarding connecting to the VPN. This is all using the built-in Windows 10 client:

If initiating the connection by clicking the network icon in the tray, selecting the VPN and clicking the inline 'Connect' button there, it will often get stuck at the 'Connecting...' stage for a while then fail.

If I go into the 'Netowrk & Internet Settings -> VPN' part of the control panel and initiate the connection from there, it succeeds 100% of the time and very quickly.

I have also been using a third-party utility called AutoVPNConnect, which periodically checks whether the VPN is active and 're-dials' it if not. I couldn't find any way to get this behaviour reliably within Windows itself. I now suspect that the unwanted route is being added when the utility re-establishes the connection. I don't believe it's doing this intentionally.

Possibly there are multiple APIs in Windows for 'dialling' a VPN, and they function slightly differently?

Edit to add: Manually assigning a metric of 1 to the local network interface, as suggested by harrymc, appears to have made the problem go away for at least a few days, even though route print shows that Windows isn't actually using that value at all. Awarded the bounty to that answer as the suggest does seem to have stopped the problem, but I don't feel I can mark anything as the actual 'answer' to my question it still isn't explained why this happened, or why it has stopped, or whether it might come back in future.

  • I don't know why the VPN got a catch-all route of, but why is the metric of your local network 192.168.0.x so high? Using the route command, try to make it 1 so it will always have precedence. Are you using the Windows VPN client? I would also advice to disable IPv6 inside the local network.
    – harrymc
    Mar 9 '19 at 16:20
  • I have the exact problem. I wrote my own AutoVPNConnect. it works just file on windows server 2016. but it didn't work on windows server 2019. after little digging i found out when i try to connect to VPN via AutoVPNConnect, it adds a default route. but if i run rasdial manually, it didn't add a default route!!!
    – Mohammad
    May 5 '19 at 5:34

I can see two weird facts when the problem occurs:

  1. The VPN has suddenly acquired a default route (, a route that didn't exist when you restarted the VPN
  2. The local routes have an unreasonably high metric value of 4500+.

As your VPN client is unspecified, I don't know if it was it that is behind it. It's certainly the one that created the default route, but this is with a very reasonable metric value of 26.

I would therefore recommend:

  • Disable IPv6 in your local network, to reduce the number of factors.
  • Set the local IPv4 connection to a metric of 1, or "best", in the Properties of the local network (disabling "Automatic metric").
  • Verify in the Properties of the VPN, Networking tab, "Internet Protocol (TCP/IP)" properties, Advanced, that "Use default gateway on remote network" is unticked. In the DNS tab, ensure that "Register this connection's addresses in DNS" is ticked.
  • I am using the built-in Windows VPN support, but also an extra third-party utility to auto-reconnect when the connection is dropped (I couldn't get any kind of 'auto-dial' functionality working properly with Windows alone). I since noticed some additional weird behaviour around that (see edit). Setting my local network metric to 1 is a good idea, thanks, I hadn't thought of that. I will try it for a couple of days and see if it works around the problem.
    – Ashley
    Mar 10 '19 at 14:28
  • How is it going?
    – harrymc
    Mar 14 '19 at 14:45
  • Haven't had the issus in a few days. Setting the local interface metric to 1 didn't actually work as expected, route print now shows it as 257. However it's now apparently decided to actually respect the metric of 10000 that I assigned to the VPN. Examined the source of AutoVPNConnect and found it does nothing but invoke rasdial.exe, so don't think it was to blame.
    – Ashley
    Mar 14 '19 at 23:27
  • I can't tell what created this metric problem, maybe it was a one-time change caused by some installation process, which hopefully will not return. It seems that monkeying with the metrics has given the system a beneficial kick in the right direction. Metric 257 is still weird, as mine is a normal 25 without any manual setting of the metric, but if everything works now there might not be reason enough to further disturb the situation.
    – harrymc
    Mar 15 '19 at 7:42

I believe you have already tried to Uncheck Automatic metric and set a low value, and failed in this way.

So I would suggest three directions:

  • Write a batch file or something to manage your VPN connection -- dial / check / re-dail.
  • Write a script to check the route table, and change it back when the thing happens.
  • Check the settings of AutoVPNConnect, see if it has some settings with routes.

It seems mostly likely your route table was changed by AutoVPNConnect, so I would suggest you to remove it and use the first way.
At least remove AutoVPNConnect first, and try manually connect/re-connect the VPN, see if the problem occurrs again.

  • The source for AutoVPNConnect is actually available, and having examined it I see it's basically just invoking rasdial.exe, nothing in there for adding or modifying any routes. I don't want to have to manually run any batch files, so I could use task scheduling to do that... but if that's also just invoking rasdial.exe I'd expect the same outcome.
    – Ashley
    Mar 14 '19 at 23:24
  • @Ashley Yes, batch is also invoking rasdial.exe. However with a custom batch file you can check the route table before and after the vpn is connected, and in a time-delayed loop, so whenever the route table messed up, the batch file can rectify it. Same mechanism can apply to other man-made demons too.
    – Tiw
    Mar 15 '19 at 3:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.