Add option to change the InterfaceMetric on the TAP32 adapter

[hildeb]

There seem to be some (just some!) installations of win10 which (like previous versions of windows) seem to have issues with the "interface order".

What we're seeing is that our INTERNAL DNS is not being used, since the LAN/WIFI adapters have higher priority.

In Windows BEFORE version 10 one could simply change this in the network settings panel, and it would even survive a reboot. In Windows 10 one has to fiddle with the interface metrics as described here:

​http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_web/cannot-change-network-binding-order-in-windows-10/08d775da-24d6-4b26-96fe-355920e879a0?page=2

My idea: wouldn't it be cool if I could specify a "InterfaceMetric?" for the TAP32 adapter in the config. Then it could be chosen suifficiently low (e.g. to zero)...

As a workaround I though of creating a pre-up script that would invoke a powershell script upon startup...

[Gert Döring]

Thanks for bringing this up - this might explain why I have seen some issues with DNS resolving on windows as well (of course, never on my own system where I could usefully debug this).

I'm not sure how or why "InterfaceMetric?" has anything to do with DNS (as from the description, this would only influence interface selection if you have multiple identical routes - which we don't have normally) but then, this is Microsoft, anything goes...

I'm not sure how to set this from within OpenVPN, though - not enough info in the article. So a powershell scriped packed into the distribution and used as --pre-up might be a good way to tackle this...

[hildeb]

I do agree. Again, I'm not seeing this on my own machine...

[hildeb]

We got several reports from Win10 users, so this is becoming a real issue.

[Samuli Seppänen]

We've also spotted this problem in the Private Tunnel and OpenVPN Connect clients. Basically DNS server settings pushed by the OpenVPN server get a lower priority on Windows 10 than the LAN/Wifi adapters. On Windows 8.1 things work as expected.

[Samuli Seppänen]

Novaflash on #openvpn-devel IRC has reported this on Microsoft forums. According to him there are other thread in there about the same problem. So it seems that the bug is in Windows, not in OpenVPN, and that Microsoft will (have to) fix this in later Windows 10 builds.

If you want to expedite fixing of this issue, please report this problem using the ​Windows 10 feedback app as suggested (to novaflash) by Microsoft. The more complaints Microsoft gets, the more likely it is this bug will get fixed in a timely manner.

[Gert Döring]

The microsoft link given references a "cmdlet"

Set-NetIPInterface –InterfaceIndex? “xx”–InterfaceMetric? “xx”

is this something we can just run from --up? No idea what a "cmdlet" is, and how to run it - but we do know the InterfaceIndex? inside OpenVPN and we could try to set the Metric to "1" to enforce the lowest possible value...

Well... the microsoft documentation here ​https://technet.microsoft.com/en-us/library/hh826125(v=wps.630).aspx shows examples, so this is something in powershell - which should be runnable from --up, or we add a small helper script which runs the correct powershell invocation...

[hildeb]

I tried invoking an "--up" script, but Win10 would always disallow the execution of Powershell "scripts". I have no clue how to circumvent this.

[Gert Döring]

The DNS leak issue was covered in more detail in #605, and starting with 2.3.9 you can put this into your config files:

setenv opt block-outside-dns

which will do nothing (print a warning) on XP and non-windows, and block all DNS activity on all non-tun/tap interfaces on Vista+ (thanks @valdikss).

Not exactly what was requested here, but good enough to block the DNS issue.

[rf]

I would like to add that it would still be great to have a knob to tune the interface metric because besides the possibility of using block-outside-dns to block DNS leaks I often face the issue (especially on Windows 10 clients), that pushed routes are not used:

Consider the scenario where a network adapter sets its interface metric to a smaller value than the OpenVPN tap adapter (either by setting the interface metric directly or by setting an arbitrary high interface speed on the adapter, so that Windows calculates a small interface metric).

This could result in a route metric (the sum of the interface and route specific metric) lower than the one of the routes pushed by OpenVPN.

I've seen such behavior from other virtual adapters, like for example commercial VPN software or virtual adapters created by mobile phone tethering, which setup their interface speeds to e.g. 40Gbps and are thus preferred in the routing table due to the low calculated interface metric.

[Samuli Seppänen]

Replying to hildeb:

I tried invoking an "--up" script, but Win10 would always disallow the execution of Powershell "scripts". I have no clue how to circumvent this.

You need to make the Powershell execution policy less strict first:

> Set-ExecutionPolicy Bypass

If you do this from an administrator Powershell prompt it will set the system's ("LocalMachine") default policy. Otherwise it probably sets the policy only for current user.

In any case, after setting the execution policy you should be able to run Powershell-based --up scripts.