Seems to me, maybe not.
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.
@alzhao - Any update? Still seems to be the same - unless I hardcode the DNS on Windows machines, local dns doesn’t resolve.
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.
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.
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
}
3 Likes
-
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
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.
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.
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.
1 Like
Can you just turn off DNS-rebind attach protection on the router?
It will be much easiler.
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.
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.
@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.
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
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
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!
1 Like
When I setup custom DNS like this:
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…
