Windows 10 won't stop using remote gateway with VPN

Question

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
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.10   4506
          0.0.0.0          0.0.0.0         On-link    192.168.12.200     26
      82.4.223.31  255.255.255.255      192.168.0.1     192.168.0.10   4251
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4556
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4556
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
      192.168.0.0    255.255.255.0         On-link      192.168.0.10   4506
     192.168.0.10  255.255.255.255         On-link      192.168.0.10   4506
    192.168.0.255  255.255.255.255         On-link      192.168.0.10   4506
   192.168.12.200  255.255.255.255         On-link    192.168.12.200    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1   4556
        224.0.0.0        240.0.0.0         On-link      192.168.0.10   4506
        224.0.0.0        240.0.0.0         On-link    192.168.12.200     26
  255.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
  255.255.255.255  255.255.255.255         On-link      192.168.0.10   4506
  255.255.255.255  255.255.255.255         On-link    192.168.12.200    281
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0      192.168.0.1  Default
===========================================================================

My home PC is (statically assigned) 192.168.0.10, with 192.168.0.1 being my home router. The network I am joining through the VPN is 192.168.12.0, 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
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.10    281
      82.4.223.31  255.255.255.255      192.168.0.1     192.168.0.10     26
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.0.0    255.255.255.0         On-link      192.168.0.10    281
     192.168.0.10  255.255.255.255         On-link      192.168.0.10    281
    192.168.0.255  255.255.255.255         On-link      192.168.0.10    281
     192.168.12.0    255.255.255.0     192.168.12.1   192.168.12.200     26
   192.168.12.200  255.255.255.255         On-link    192.168.12.200    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.0.10    281
        224.0.0.0        240.0.0.0         On-link    192.168.12.200    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.0.10    281
  255.255.255.255  255.255.255.255         On-link    192.168.12.200    281
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0      192.168.0.1  Default
===========================================================================

Only traffic for 192.168.12.0 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.

Solution 1

I can see two weird facts when the problem occurs:

1. The VPN has suddenly acquired a default route (0.0.0.0), 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 0.0.0.0 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.

Solution 2

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.

Comments

[Ashley]

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.

[harrymc]

How is it going?

[Ashley]

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]

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.

[Tiw]

@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.

[harrymc]

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.