Browsers' domain name resolution is not done through VPN if GUI wasn't started with "Run as adminitstator"

[tom.ty89]

I became aware of this problem when I connect a VPN server in some other country from China, since it is known that our country will hijack certain domain name resolution (for whatever reasons).

Say I connect a VPN server in the UK, I can then watch programmes on bbc.co.uk, yet I still can't access google or any site with names containing "vpn" (e.g. openvpn.net) with Firefox or Edge. (However, if I do domain name resolution with nslookup, it appears that the resolution is done through the VPN.)

This does not happen if I started the GUI with "Run as administrator", or running openvpn with cmd/ps started with that. (While if cmd/ps is not started with that, openvpn cannot complete initializing the connection at all, which is pretty much expected).

The only difference in the log is the following additional line shown when the GUI is NOT started with "Run as administrator":
Flag 'def1' added to --redirect-gateway (iservice is in use)

I am using Windows 10 RS2 and openvpn-install-2.4.3-I601.exe.

[Selva Nair]

What DNS servers are set on tap and other (wifi, ethernet etc.) adapters? Does ping www.google.com work or does it also fail to resolve the name? Please post the config and output of "route print" when the connection is started as admin and otherwise.

[tct]

watching

[tom.ty89]

My NIC is configured statically for both IP addresses and DNS servers, with the DNS servers being set to 8.8.8.8/8.8.4.4. The TAP is apparently configured via DHCP for both for those, with the DNS servers set to the same pair.

No ping does not resolve to authentic addresses either.

Will attach requested info. In the attachments the VPN server address will be replaced with x.x.x.x.

[tom.ty89]

config (.opvn)

[tom.ty89]

nslookup / ping / route print (without VPN connection)

[tom.ty89]

nslookup / ping / route print (GUI started in non-admin mode)

[tom.ty89]

nslookup / ping / route print (GUI started in admin mode)

[Selva Nair]

As far as routes go, the only difference between is that redirect gateway sets up two routes to 0.0.0.0/1 and 128.0.0.0/1 when run without admin rights. This should not cause any functional difference to the connection. So something else is going on.

Based on the difference between addresses resolved by nslookup and ping I suspect you are getting a DNS server set on the TAP adapter only when run as admin -- note that nslookup (which uses a direct connection to 8.8.8.8) resolves www.google.com as 216.58.200.4 while ping (which uses the DNS client service) gets different results depending on how the tunnel is started.

Your config shows no --dhcp-option DNS, but probably one is getting pushed by the server. Please post logs with verb=4 with and without admin and also check what DNS servers are set on the TAP adapter after the connection (ipconfig /all).

[tom.ty89]

After some more tests it appears to me that the route difference is exactly the cause of the problem.

First of all I cannot provide you a more detailed log with the server used in the last tests because the provider has been shut down. Its DHCP server did push DNS servers and they are 8.8.8.8 and 8.8.4.4. I actually mentioned that already in my last post.

When I test with other servers (from other providers), the problem no longer shows only with non-admin mode but has become a general case. Apparently the reason is they all pushes 'redirect-gateway def1', coz I don't see 'Flag 'def1' added to --redirect-gateway (iservice is in use)' anymore and the '0.0.0.0 0.0.0.0' route remains unchanged.

I will be attaching a test case that should be enough to show that the route is the reason. Again the VPN server address would be replaced with x.x.x.x.

[tom.ty89]

DNS resolution with ping and nslookup before/after route change

[Selva Nair]

Clearfly dns client service is resolving names through the LAN interface which is not what you want. This is not surprising as Windows 10 is known to do DNS resolution in parallel through all interfaces. But why this shows up only when the default route is over-ridden by the two /1 routes is beyond me..

You may be able to fix this using --block-outside-dns in the config which will firewall out dns traffic through all adapters other than TAP.

[tom.ty89]

Yeah block-outside-dns works. Considering the fact that this option is Windows-specific, I guess what I've been experiencing is more or less a known defect?

I just got one more question. Sorry if it's a bit off-topic. Because some servers just pushes 'redirect-gateway def1', apparently, so I've been wondering if there's a decent way to undo the def1 flag. Here is way I thought of:

route-nopull
redirect-gateway

But the problem is route-nopull also rejects 'dhcp-option' the server pushes. So my question is, is there a way to only reject the 'redirect-gateway' (or even only the 'def1' flag) it pushes but not the dhcp-option?

Or is there at least a way to set dhcp-option back so that I don't need to specify a DNS server myself (e.g. dhcp-option DNS 8.8.8.8) but use whatever comes from the DHCP server?

[Selva Nair]

pull-filter ignore "redirect-gateway def1"
redirect-gateway