Opened 4 years ago

Last modified 3 years ago

#596 new Feature Wish

Add option to change the InterfaceMetric on the TAP32 adapter

Reported by: hildeb Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.8 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Samuli Seppänen

Description

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

Change History (10)

comment:1 Changed 4 years ago by Gert Döring

Cc: Samuli Seppänen added

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

comment:2 Changed 4 years ago by hildeb

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

comment:3 Changed 4 years ago by hildeb

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

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by 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.

comment:6 Changed 4 years ago by 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...

comment:7 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by 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.

comment:9 Changed 3 years ago by 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.

comment:10 in reply to:  7 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.