Wireguard client not honoring DNS setting [workaround discovered]

axebro · 2020-12-23T22:53:37.736Z

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 · 2021-04-02T03:12:29.237Z

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

alzhao · 2021-04-03T02:43:02.930Z

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 · 2021-05-17T21:59:38.251Z

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 · 2021-05-17T23:48:23.147Z

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 · 2021-05-18T00:26:44.307Z

king_growler:

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.

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 · 2021-05-19T05:51:59.755Z

crahan:

A followup to my previous comment.

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 · 2021-05-19T08:46:00.654Z

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 · 2021-10-19T19:02:02.187Z

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 · 2021-10-20T01:19:19.817Z

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

It will be much easiler.

johhen · 2021-10-20T03:11:25.184Z

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 · 2021-12-27T21:44:57.230Z

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.

axebro · 2022-01-31T17:01:23.796Z

@alzhao any update on getting this working?

It looks like the bug report that’s linked in the previous posts isn’t correct. I’m having to use IP addresses for my LAN side services. That works with with some services - but not all.

For what it’s worth - my Wireguard server is a Brume, and client is a Beryl. When I connect to WG server on Brume using my android phone’s WG client, name resolution works exactly as expected.

gli_user · 2022-04-24T22:35:54.866Z

How to use more than one DNS? It works if I enter only 1.1.1.1, but with more Server (to be on the safe side for some countries, which will block specific ones) it does not work.

I.e. 5.9.164.112, 185.95.218.42, 185.95.218.43, 84.200.69.80, 9.9.9.9, 1.1.1.1 is not working (wrong DNS6 Server, or similar error)
1.1.1.1 allone works

wcs2228 · 2022-04-25T02:13:12.686Z

Try each DNS IP address individually to see which may be causing the problem.

I do not work for and I am not directly associated with GL.iNet

Maximilious · 2022-06-05T12:54:51.964Z

THANK YOU! I bought one of these routers after seeing the reviews and hit this issue during my initial setup and testing. Your fixes worked flawlessly for me!

JERKBALL · 2022-06-08T20:34:02.921Z

When I setup custom DNS like this:

wireguard-custom-dns

My tethering setup just uses this config:
See post 2 ( I’m Newbee)

But when I look at my wireguard config… GUI tells me my IP is the same as my DNS…? Something is wrong there

See post 3 ( I’m Newbee)

Anything I can provide to fix this issue?

Android cellphone working wonderful with my wireguard server and dns…

Even using openwrt 21.02.3 and gl.inet hardware works with wireguard and dns…

JERKBALL · 2022-06-08T20:34:44.249Z

wireguard-tethering-dns

JERKBALL · 2022-06-08T20:35:26.876Z

wireguard-ip-address

wcs2228 · 2022-06-09T03:05:36.074Z

The IP addresses 10.13.37.50 and 127.0.0.1 are not valid DNS servers. You should not need to use manual DNS settings for normal router traffic, but if you want to, then try Cloudflare 1.1.1.1 and/or 1.0.0.1.

The WireGuard config file should also the VPN provider’s DNS IP address(es) for tunnel traffic.