Wireguard client not honoring DNS setting [workaround discovered]

king_growler · July 9, 2019, 7:26pm

edit: see below posts for workaround.

I’m using an AR-750, running testing firmware “openwrt-ar750-3.022-0329”. It is configured as a wireless AP for my devices, and is directly plugged in via ethernet cable to a switch in my AirBnB.

I do have custom DNS settings configured, however I am also using the AR750 as a Wireguard client. My issue is that the device does not configure DNS correctly. My client devices always use the upstream devices DNS server.

When I ssh into the AR750, I can see that /etc/resolv.conf is pointing at /tmp/resolv.conf, however /tmp/resolv.conf is a link to /tmp/resolv.conf.auto. This file has the upstream DNS nameserver. There is also a /tmp/resolv.conf.vpn, which has the DNS server for my Wireguard VPN.

I can manually change the link in /tmp/resolv.conf to point to /tmp/resolv.conf.vpn, and name resolution works correctly on the AR750 only, however even when I restart dnsmasq service, my wireless clients are not using the Wireguard DNS – they all still use the upstream device’s nameserver, via the AR750.

How can I configure the AR750 to correctly use the Wireguard DNS nameserver? As mentioned, I can manually make this change, however it is not propagated to the wireless client devices. If I run nslookup or dig on a wireless client (eg, a linux laptop) it shows that the AR750 is the nameserver, however it cannot resolve names on the Wireguard VPN, even though the AR750 can do so after I change the link in /tmp.

In case this isn’t clear, here is what is happening (192.168.8.1 is the AR750):

Client wireless device cannot do lookup on Wireguard VPN:

[bongo@gally-959E ~]$ nslookup ns1
Server:         192.168.8.1
Address:        192.168.8.1#53

Non-authoritative answer:
*** Can't find ns1: No answer

AR750 gets the same answer, until I change link on /tmp/resolv.conf → /tmp/resolv.conf.vpn, then:

root@GL-AR750:~# nslookup ns1
Server:         10.7.1.53
Address:        10.7.1.53#53

Name:      ns1
Address 1: 10.7.1.53

However, even when I make this change on the AR750, it never affects client devices.

Any help is appreciated!

kyson-lok · July 10, 2019, 10:44am

The traffic from router itself will always use the upstream DNS even you have set manual DNS.

The client connected to AR750 will use always use AR750 as DNS server, unless you set an assign DNS server for your PC. So it is the normal behavior.

But if you have set the manual DNS on AR750, it will use the DNS server as upstream DNS server. To test DNS, you should use https://dnsleaktest.com/ instead.

Could you please ssh to the router, and execute cat /etc/config/dhcp after you start WireGuard?

king_growler · July 10, 2019, 11:12am

Thank you for the reply. I understand that my clients will use the AR750 as DNS server, however I can never resolv names using the Wireguard VPN DNS server.

Here is my /etc/config/dhcp; I can see that resolvfile is set to the correct file /tmp/resolv.conf.vpn, however I can never resolv names on the client only the AR750:

config dnsmasq
option domainneeded ‘1’
option boguspriv ‘1’
option filterwin2k ‘0’
option localise_queries ‘1’
option rebind_localhost ‘1’
option local ‘/lan/’
option domain ‘lan’
option expandhosts ‘1’
option nonegcache ‘0’
option authoritative ‘1’
option readethers ‘1’
option leasefile ‘/tmp/dhcp.leases’
option localservice ‘1’
option rebind_protection ‘0’
list server ‘9.9.9.9’
list server ‘149.112.112.112’
option noresolv ‘1’
option resolvfile ‘/tmp/resolv.conf.vpn’

config dhcp ‘lan’
option interface ‘lan’
option start ‘100’
option limit ‘150’
option leasetime ‘12h’
option force ‘1’
option dhcpv6 ‘server’
option ra ‘server’
option ignore ‘0’

config dhcp ‘wan’
option interface ‘wan’
option ignore ‘1’

config odhcpd ‘odhcpd’
option maindhcp ‘0’
option leasefile ‘/tmp/hosts/odhcpd’
option leasetrigger ‘/usr/sbin/odhcpd-update’

config domain ‘localhost’
option name ‘console.gl-inet.com’
option ip ‘192.168.8.1’

config dhcp ‘guest’
option interface ‘guest’
option start ‘100’
option leasetime ‘12h’
option limit ‘150’
option dhcpv6 ‘server’
option ra ‘server’

king_growler · July 11, 2019, 7:37am

I have fixed this problem by implementing the fixes described by @PaulS in this post:

AS-750S Slate Rotuer: DNS fix to allow use of internal DNS server with Wireguard Client

In the post he links to a blog wherein he describes the changes in detail:

GL-iNet GL-AR750S-Ext mss clamping mtu_fix for Wireguard VPN

Note: I did not need to implement the mtu_fix, only the two dns fixes.

You can read about how to make this change in @PaulS blog above. Here is a patch for “/etc/init.d/wireguard” file on the AR750:

--- /etc/init.d/wireguard.old	2019-07-11 09:30:43.563687226 +0200
+++ /etc/init.d/wireguard	        2019-07-11 09:30:25.301885360 +0200
@@ -95,6 +95,7 @@
 		#mv /tmp/resolv.conf.auto /tmp/resolv.conf.auto.hold
 		echo -e "nameserver $dns" > /tmp/resolv.conf.vpn
 		uci set dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.vpn'
+		uci add_list dhcp.lan.dhcp_option="6,$dns"
 		uci commit dhcp
 		/etc/init.d/dnsmasq restart
 	else
@@ -382,6 +383,7 @@
 	[ -f "/tmp/resolv.conf.vpn" ] && {
 	rm -rf /tmp/resolv.conf.vpn
 	uci set dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
+	uci del_list dhcp.lan.dhcp_option="6,$dns"
 	uci commit dhcp
 	/etc/init.d/dnsmasq restart
 	}

king_growler · July 11, 2019, 8:00am

I have opened 0000226: GL-AR750 Wireguard does not pass wireguard DNS server to DHCP clients to track this future fix.

adirano · September 5, 2020, 6:17pm

This one is still open, isn`t it? (I cant see the status of GL.iNet - Connecting The World To Secure Wi-Fi)
I have a 300N-V2 as a Wireguard client and have the wireguard option DNS-configured to use an internal DNS - but my clients behind the 300N-V2 dont get this setting?

alzhao · September 8, 2020, 4:15am

This has been fixed, hasn’t it?

adirano · September 19, 2020, 9:23am

Seems to me, maybe not.

axebro · December 23, 2020, 10:53pm

I’m still seeing same issue on the latest 3.105 firmware on AR300M device. Any devices connected to the router seem to use the upstream DNS server, so that’s good. But it cannot seem to resolve the hosts that are on the WireGuard server’s lan.

On my windows clients, if I hard code the DNS to the internal lan’s DNS server, everything works. I have the DNS server specified on the Wireguard client config page.

axebro · April 2, 2021, 3:12am

@alzhao - Any update? Still seems to be the same - unless I hardcode the DNS on Windows machines, local dns doesn’t resolve.

alzhao · April 3, 2021, 2:43am

Sorry I do not have progress but now the firmware has been upgraded to 3.201. Can you try the new one and report back
https://dl.gl-inet.com/firmware/snapshots/3.201_beta6/

A lot of thing changed.

crahan · May 17, 2021, 9:59pm

Tested on 3.201 on an AR750S.

When using DNS over TLS as custom DNS servers, option noresolv '1' is automatically added to /etc/config/dhcp which makes dnsmasq ignore /etc/resolv.conf (or any file configured for the option resolvfile entry in /etc/config/dhcp).

As a result, using DNS over TLS as custom DNS servers in combination with a WireGuard client setup that provides its own DNS server won’t work.

Enabling the WireGuard client will:

create /tmp/resolv.conf.vpn
add option resolvfile '/tmp/resolv.conf.vpn' to /etc/config/dhcp
restart dnsmasq

But due to the noresolv '1' entry in /etc/config/dhcp, /tmp/resolv.conf.vpn is never used.

As far as I can see the only way to solve this when using DNS over TLS is to change list server '127.0.0.1#53535' in /etc/config/dhcp to list server '$dns' (with $dns the configured DNS server in the WireGuard client settings) when enabling the WireGuard client connection.

This way DHCP clients can keep using the AR750S as their DNS server and the device will then forward all DNS lookups to the WireGuard DNS server instead of the local stubby server running at 127.0.0.1#53535.

crahan · May 17, 2021, 11:48pm

Update: now using dhcp.@dnsmasq[0].noresolv.

A followup to my previous comment.

I solved the issue in /etc/init.d/wireguard by checking if Stubby is enabled and if it is, removing the entry from the dnsmasq forwarders list and setting dhcp.@dnsmasq[0].noresolv=0 to force dnsmasq to use /tmp/resolv.conf.vpn.

When disconnecting from the VPN I revert the DNS forwarder value back to the default Stubby forwarding address (127.0.0.1#53535) and revert back to dhcp.@dnsmasq[0].noresolv=1 to ignore /tmp/resolv.conf.auto.

If DNS over TLS (and Stubby) is not used then the /tmp/resolv.conf.auto and /tmp/resolv.conf.vpn files will be used instead. Below is the patch file with my edits.

--- wireguard.orig	2021-05-18 01:12:07.000000000 +0200
+++ wireguard	2021-05-18 10:58:47.000000000 +0200
@@ -18,6 +18,7 @@
 ipv6_status="$(ifstatus wan6 2>/dev/null|grep '\"up\": true')"
 ipv6_enable="$(uci get glipv6.globals.enabled)"
 mode6=$(uci get glipv6.lan.mode)
+stubby_enable=$(uci get stubby.global.enable)

 proxy_func()
 {
@@ -115,6 +116,11 @@
 			echo -e "nameserver $dns" > /tmp/resolv.conf.vpn
 		fi
 		uci set dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.vpn'
+		# Replace Stubby forwarder with VPN DNS
+		[ "$stubby_enable" = 1 ] && {
+    		uci delete dhcp.@dnsmasq[0].server
+    		uci set dhcp.@dnsmasq[0].noresolv=0
+		}
 		uci commit dhcp
 		/etc/init.d/dnsmasq restart
 	else
@@ -377,6 +383,12 @@
 		[ -f "/tmp/resolv.conf.vpn" ] && {
 			rm -rf /tmp/resolv.conf.vpn
 			uci set dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
+			# Restore stubby forwarder
+			[ "$stubby_enable" = 1 ] && {
+    			uci delete dhcp.@dnsmasq[0].server
+    			uci add_list dhcp.@dnsmasq[0].server='127.0.0.1#53535'
+			    uci set dhcp.@dnsmasq[0].noresolv=1
+			}
 			uci commit dhcp
 			/etc/init.d/dnsmasq restart
 		}
@@ -538,6 +550,12 @@
 	[ -f "/tmp/resolv.conf.vpn" ] && {
 	rm -rf /tmp/resolv.conf.vpn
 	uci set dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
+	# Restore stubby forwarder
+	[ "$stubby_enable" = 1 ] && {
+    	uci delete dhcp.@dnsmasq[0].server
+    	uci add_list dhcp.@dnsmasq[0].server='127.0.0.1#53535'
+		uci set dhcp.@dnsmasq[0].noresolv=1
+	}
 	uci commit dhcp
 	/etc/init.d/dnsmasq restart
 	}
@@ -631,6 +649,12 @@
 		[ -f "/tmp/resolv.conf.vpn" ] && {
 			rm -rf /tmp/resolv.conf.vpn
 			uci set dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
+			# Restore stubby forwarder
+			[ "$stubby_enable" = 1 ] && {
+    			uci delete dhcp.@dnsmasq[0].server
+    			uci add_list dhcp.@dnsmasq[0].server='127.0.0.1#53535'
+			    uci set dhcp.@dnsmasq[0].noresolv=1
+			}
 			uci commit dhcp
 			/etc/init.d/dnsmasq restart
 		}

Henry_Bruns · May 18, 2021, 12:26am

Now I have seen your bugreport. It can be its the same DNS leak which I reported for OpenVPN for gl firmware >3.105 for AR-300, AR750 and AR-750S.
The good news ist, they are no DNS leak by OpenVPN by AR-300, AR750 and AR-750S router, by useing the 3.105 firmware.
Firmware openwrt-ar750s-3.201-0402.tar, possible still same DNS leak or again - #27 by Henry_Bruns

DeepAnger · May 19, 2021, 5:51am

I’ve tried this (MV1000 3.203). It worked for the LAN client routed in the VPN but the client excluded did not have working DNS resolution.

crahan · May 19, 2021, 8:46am

This configuration does assume all traffic goes over the WireGuard VPN.

For split tunneling setups things would need to be changed to use the WireGuard DNS server for clients routed over the VPN and another for clients being excluded from the VPN.

johhen · October 19, 2021, 7:02pm

My search for wireguard DNS issues led me here. However, my issues were actually different. My issues turned out to be related to binding redirection protection. possible DNS-rebind attack detected: helloworld.lan.

In my case, I had to add the following, in all the same places @crahan did for his stubby related changes.

On:
        uci add_list dhcp.@dnsmasq[0].rebind_domain='/lan/'
        uci delete dhcp.@dnsmasq[0].local
        uci delete dhcp.@dnsmasq[0].domain
        uci commit dhcp
        /etc/init.d/dnsmasq restart
Off:
            uci delete dhcp.@dnsmasq[0].rebind_domain
            uci set dhcp.@dnsmasq[0].domain="lan"
            uci set dhcp.@dnsmasq[0].local='/lan/'
            uci commit dhcp
            /etc/init.d/dnsmasq restart

Now, I can access all my servers within the network I connect to over wireguard.

alzhao · October 20, 2021, 1:19am

Can you just turn off DNS-rebind attach protection on the router?

It will be much easiler.

johhen · October 20, 2021, 3:11am

Yeah - that was the other option, just change that setting. Could do the same thing editing the wireguard conf file to just turn that setting off/on, or just turn it off always. I couldn’t easily find it in the GUI to disable always, so I figured why not toggle it with this.

axebro · December 27, 2021, 9:44pm

Seems to still be an issue, regardless of DNS Rebind or DNS server specification.

Using firmware Version 3.211.

I know it’s not the tunnel, because my DNS lookups work fine if I’m using my Android Wireguard client to connect to the same wireguard server. It’s specifically the way they gli devices handle the lookup.