Changing metric instead adding

[IPTRACE]

Hello!

Regarding my thread on OpenVPN forum I'd like to report bug for changing interface metric on Windows.

​https://forums.openvpn.net/viewtopic.php?f=4&t=23103

It's better to use "netsh" command instead "route" in Windows to change the metric.

Example changes metric value:
netsh.exe interface ipv4 set interface 25 metric=5

Example adds metric value to current value:
route.exe ADD 10.0.0.0 MASK 255.255.254.0 10.10.11.1 METRIC 5

[Selva Nair]

2.2.2 is an ancient version. Use 2.4 and let interactive service do the job. If that sets the metric wrong, please post the config and verb=4 log.

In 2.4, route.exe is used only if interactive service is not in use, and on top of that route-method is set to exe or IP helper API fails. Its best to leave route-method unspecified in the config. That option should be deprecated.

[IPTRACE]

Windows OpenVPN 2.4.0 client log with verbosity 4.

[IPTRACE]

Sorry, my mistake. It should be 2.4.0. I've attached log file.

[IPTRACE]

Config file.

[Selva Nair]

Those lines in the log like

C:\WINDOWS\system32\route.exe ADD 10.10.10.0 MASK 255.255.254.0 10.10.11.129 METRIC 5

are purely informational or what would have been executed if the route-method was exe. What the service actually does is to call CreateIpForwardEntry2(..) with the specified prefix, nexthop (gateway) and metric.

On Windows the route metric has to be always greater than or equal to the interface metric so the number specified in this call is the metric offset: the metric you see in 'route print' will be this number + the metric of the underlying interface. For example, if the interface metric is 20, you will get 25 in the above case.

I could not access the forum post but the netsh command you mentioned changes the interface metric and affects all routes on that interface. The addition of route and interface metric is done dynamically, so if you change the interface metric using netsh or an API call from say 20 to 10, the metric of all routes set on that interface will automatically decrease by 10.

The interface metric for TAP adapter is currently assigned automatically, I suppose. On my windows 7 laptop its 20 which makes sense as the tap driver declares a 100 mbps interface for which Windows would choose 20.

[IPTRACE]

All is clear but due to internal DNS issue I have to set lower metric value (higher priority) for the OpenVPN tap. So, for every station I have to set metric exp. to 5.
When my metric has lower priority I can not contact DNS servers which are in VPN network.

[Selva Nair]

Your config has block-outside-dns. So independent of metric, DNS requests will go exclusively through the VPN tunnel. Are you saying that if metric is not lowered, DNS through VPN does not work at all?

[IPTRACE]

Yes, exactly.

Please look at my print route and ping commands and look at the metric in both cases.
I had that problem on 2.3 versions and 2.4 as well.
push "route-metric 5" is set on server configuration.

10.0.0.16 - DNS server (internal and proxy)
104.20.85.245 - openvpn.net

1. TAP interface has automatic metric set.

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 192.168.8.1 192.168.8.107 25

10.0.0.0 255.255.254.0 10.10.10.1 10.10.10.2 40

10.10.10.0 255.255.254.0 10.10.10.1 10.10.10.2 40
10.10.10.0 255.255.255.128 On-link 10.10.10.2 291
10.10.10.2 255.255.255.255 On-link 10.10.10.2 291

10.10.10.127 255.255.255.255 On-link 10.10.10.2 291

ping commands:
Ping statistics for 10.0.0.16:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\Users\>ping openvpn.net
Ping request could not find host openvpn.net. Please check the name and try again.

2. TAP interface has manual metric set to 1.

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 192.168.8.1 192.168.8.107 25

10.0.0.0 255.255.254.0 10.10.10.1 10.10.10.2 6

10.10.10.0 255.255.254.0 10.10.10.1 10.10.10.2 6
10.10.10.0 255.255.255.128 On-link 10.10.10.2 257
10.10.10.2 255.255.255.255 On-link 10.10.10.2 257

10.10.10.127 255.255.255.255 On-link 10.10.10.2 257

ping commands:
Ping statistics for 10.0.0.16:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Ping statistics for 104.20.85.245:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

[IPTRACE]

I've disabled block-outside-dns and resolving works fine and is not depended of metric value... but it's a DNS leak now, isn't it?
Internet DNS queries flow via my ISP and my local servers resolving is via DNS proxy but with block-outside-dns enabled DNS queries flow via my internal DNS proxy server in VPN network in both Internet and local resolving.

[Selva Nair]

Replying to IPTRACE:

Yes, exactly.

Please look at my print route and ping commands and look at the metric in both cases.
I had that problem on 2.3 versions and 2.4 as well.
push "route-metric 5" is set on server configuration.

As I wrote before "route-metric 5" will cause all routes to be set with metric offset of 5 (i.e metric = interface metric + 5) and the routing table shows that to be case. We could improve the man page to reflect that.

I've disabled block-outside-dns and resolving works fine and is not depended of metric value...

I have no idea why DNS through the tunnel does not work unless the metric is lowered. What version of Windows?

[IPTRACE]

Windows 10 with the newest updates.
As I remember I had the same problem on Windows 8.1 and the first Windows 10 as well then I've found route-metric.

My configuration pushes for VPN clients only NS servers from VPN network.
No outside NS are set.

1. With block-outside-dns blocks dns traffic except dns from interface with the lowest metric.
2. Without block-outside-dns dns Internet traffic flow via ISP NS servers and local domain resolving is via NS from VPN network.

[Selva Nair]

Replying to IPTRACE:

My configuration pushes for VPN clients only NS servers from VPN network.
No outside NS are set.

1. With block-outside-dns blocks dns traffic except dns from interface with the lowest metric.

--block-outside-dns just blocks dns traffic on all interfaces except the tunnel (VPN) interface. It doesn't care about metric.

[IPTRACE]

In my case metric is relevant.
I can provide additional logis if necessary.

[steMos]

Simliar behaviour for me.
Route metric is relevant.

OpenVPN Client 2.4.0-I601
Windows 10 Pro
OpenVPN 2.3.11 amd64-portbld-freebsd10.3 Server

My exact behaviour is:

with "--block-outside-dns":
nslookup public.domain.com: fails (timeout for request on public DNS)
nslookup my.domain.local: fails (timeout for request on public DNS)
nslookup public.domain.com <IP of my DNS server>: works.
nslookup my.domain.local <IP of my DNS server>: works.

without "--block-outside-dns":
nslookup public.domain.com: works (on public DNS)
nslookup my.domain.local: fails (on public DNS, obviously)
nslookup public.domain.com <IP of my DNS server>: works.
nslookup my.domain.local <IP of my DNS server>: works.

If I lower the metric of the route or of the TAP interface everything works through my custom DNS.

So, in my case at least, seems that the "block-outside-dns" works, but the default route to the DNS is used.

[Selva Nair]

nslookup opens a connection to port 53 on the sepcified server while the dns-client service uses interface-specific dns servers one after the other (or in parallell on some versions -- win10?). Also the default server that nslookup uses may not be the one you really want it to use. Actually your tests do show that default dns server used by nslookup is not the one on thetap interface. That's why it works when you specify the ip of the reachable server. This may be fixable by changing the interface order but its rarely important. What is relevant is whether the dns-client service can resolve names.

So first make sure dns client service is running and then try this with block-outside-dns on and with route metric left at the default values:

ping www.google.com
ping "my.domain.local"

Both should work. And both will fail if names cannot be resolved. Flush the cache first to be sure.

You can also use sites like www.dnsleaktest.com to find which dns servers are being contacted for name resolution.

[steMos]

Thanks,
you are right selvanair, with ping it's working as you described.

[Antonio Quartulli]

@selvanair I haven't fully understood the flow of events in this ticket as I lack a bit (well a bit more than a bit) of understanding of the windows code: would you conclude that everything is working as expected (maybe the manpage can be improved)? Or do you see a bug/misbehaviour?