Wireguard client not honoring DNS setting [workaround discovered]

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.

alzhao · 2022-06-09T04:41:18.710Z

10.13.37.50 is the router itself. It does not make sense to use it as custom DNS server.

JERKBALL · 2022-06-10T22:31:58.831Z

10.13.37.50 is my pi-hole running on a raspi…

127.0.0.1 was just for testing to get rid of the broadcasted DNS by my tethering device…

But it always uses the broadcasted DNS Server, which is 192.168.8.1 in my case (LTE Hilink Stick)

The Wireguard Server is self-hosted…

Thats why I wrote, that there are no issues connecting via android cellphone or laptop…

Just want to help getting on with troubleshooting the problem…

wcs2228 · 2022-06-11T14:46:05.757Z

Can you post the self-hosted Wireguard config file (with the keys redacted)? What is the IP address that it assigns to the client and does it assign a DNS to the client?

If I understand your network setup correctly, the Wireguard config may be assigning the client with IP address 10.13.37.x. The pi-hole has IP address 10.13.37.50 and is on the LAN side of the router, so it is not reachable because the router VPN client goes through the WAN side. Tethering is on the WAN side and DNS 10.13.37.50 is shown on your “Tethering” screenshot.

The android cellphone and laptop may be working because they are on the LAN side of the router, so the the pi-hole on the LAN side is reachable.

JERKBALL · 2022-06-13T02:08:25.405Z

Wireguard is a vpn technology, that is used outside of your wifi to access your local lan via foreign wifi or mobile network…

But due to its flawless roaming functionality it doesn’t matter, if you still use it, when you are back home in your own wifi, where you are in you local lan… its just more overhead and maybe slower…

The dns is defined in the client wireguard config with the option DNS … So the client wireguard daemon sets the dns setting… the server does not push the setting as you might know from openvpn…

The network witch wireguard uses internal is of course another subnet as the hom lan network…

[Interface]
Address = 10.13.32.1/24,fd42:42:42::1/64
ListenPort = 53120
PrivateKey = 
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o enp2s0f0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -o enp2s0f0 -j MASQUERADE

[Peer]
PublicKey = 
AllowedIPs = 10.13.32.2/32,fd42:42:42::2/128

[Peer]
PublicKey = 
AllowedIPs = 10.13.32.3/32,fd42:42:42::3/128

[Peer]
PublicKey = 
AllowedIPs = 10.13.32.4/32,fd42:42:42::4/128

[Peer]
PublicKey =
AllowedIPs = 10.13.32.5/32,fd42:42:42::5/128

[Peer]
PublicKey = 
AllowedIPs = 10.13.32.6/32,fd42:42:42::6/128

[much more peers]

The openvpn side of the gl.net software uses a /etc/openvpn/update-resolv-conf

Maybe Wireguard needs a similar script for changing the dns after proper connection to the server…

By the way I moved to another location and i am using wifi as wan connection now…

Problem still persists… I manually edit /etc/resolv.conf after proper wireguard connection, because the dns submitted via wifi connection from my wan provider can’t be reached afterwards…

After changing resolv.conf “opkg update” finds its servers again…

Thanks for your support never the less…

alzhao · 2022-06-13T05:08:07.103Z

Just in the wireguard connection screenshot it displays “10.13.37.50”. This is the IP the router use to connect to the wireguard server.

As this conflict with what you said, 10.13.37.50 is your pi-hole, not sure why this works.

JERKBALL · 2022-06-13T15:23:59.411Z

Oh, now I see what you mean…

Must be a parsing failure or something like that…

Wireguard Connection uses a public IP…

Internal the wireguard server runs on 10.13.37.170 so that is definetly wrong…

When I’m back at my laptop I can copy the raw config to my wireguard server if you want a proof…

But all that doesn’t circle the main failure happening here…

JERKBALL · 2022-06-13T16:25:40.626Z

This is my /etc/config/wireguard:

config proxy
        option main_server 'Wireguard@Zuhause'
        option access 'ACCEPT'
        option enable '1'
        option host '87.79.***.***'

config peers 'wg_peer_815'
        option name 'Wireguard@Zuhause'
        option private_key ''
        option end_point '87.79.***.***:53120'
        option public_key ''
        option persistent_keepalive '25'
        option listen_port '59099'
        option address '10.13.32.6/32'
        option dns '10.13.37.50'
        option allowed_ips '0.0.0.0/0'

alzhao · 2022-06-14T07:01:31.134Z

The address is '10.13.32.6/32', so very strange it display 10.13.37.50 in the screenshot you posted.

Can you double verify if it is a display bug? I cannot replicate this problem in my side.

JERKBALL · 2022-06-18T00:58:47.004Z

Sorry for the delay, but I’m actually in my holiday, where I need my gl.inet

But there will be low days and I will flash the beta to reconfirm the bug…

But that has nothing to do actually with the dns issue we are all complaining here

NeoMatrixJR · 2022-08-17T18:06:45.415Z

I just pulled the latest beta firmware to my Beryl and I can confirm it’s still not using my wireguard DNS.
I did just find though that if I go in to LuCI → Network → DHCP and DNS: all the settings look right and if I just hit save & apply it updates /etc/resolv.conf and work correctly. Sounds like something needs updated in the script for activating/connecting wireguard to complete the DNS change over assuming the field is populated…
UPDATE/CORRECTION - the router itself (SSH) would now use the proper DNS…however, connected clients do not.

alzhao · 2022-08-18T09:28:49.344Z

NeoMatrixJR:

UPDATE/CORRECTION - the router itself (SSH) would now use the proper DNS…however, connected clients do not.

Did you use dnsleaktest to actually test the dns server your clients are using?

NeoMatrixJR · 2022-08-18T19:32:44.819Z

No, just nslookup/dig cli tools

agnelli · 2023-04-09T05:14:07.336Z

I am also experiencing DNS issues using a Wireguard client file on my GL-MT1300 using an upgraded beta version of the firmware openwrt-mt1300-4.1.0-1107-1667792228.bin. I also experienced the problem on older versions of the firmware.

The router seems to use DNS servers from my VPS, which is in this case from the network Vultr, instead of the DNS servers specified by the Wireguard server. When I connect directly to the Wireguard server from my laptop, instead of connecting to the Wireguard server at the router level, the correct DNS servers are used.

To setup the Wireguard server I have used GitHub - trailofbits/algo: Set up a personal VPN in the cloud to create a Wireguard server on the cloud network Vultr. Looking at how that script generally sets up DNS at algo/config.cfg at master · trailofbits/algo · GitHub, it defaults to Cloudflare along with dns adblocking.

I am testing DNS using DNS leak test. Free check. I have no idea which steps to try and copy here to resolve the issue.

alzhao · 2023-05-25T06:22:58.506Z

agnelli:

openwrt-mt1300-4.1.0-1107-1667792228.bin

Pls just upgrade to latest version.

doczenith1 · 2023-05-26T02:49:51.051Z

I think I may also be experiencing this DNS issue with WireGuard. I self host my WireGuard server at my house. I have Android clients that work as expected and use the DNS provided by my WireGuard server. The WireGuard client config includes DNS = 192.168.1.1 which is the IP address of my router that is hosting the WireGuard server. I am using similarly generated config file on my X3000 but devices connected to X3000 are using the DNS servers entered in X3000 settings.

Edit: firmware 4.3.1.

Edit 2: the tunnel is working properly otherwise. The clients reported IP address is the IP address of the server.

mpfl · 2024-01-27T01:26:36.821Z

I’m experiencing this issue as well. My GL-MT1300 Beryl (firmware 4.3.7) does not honour the DNS settings from the Wireguard client. I can reach the Wireguard DNS when I specify it in nslookup, but the Beryl still uses the DNS server from the WAN.

mpfl · 2024-01-27T01:40:28.642Z

Oh, I also noticed that the GL.iNet UI doesn’t respect valid Wireguard configuration options. For example, Wireguard lets you add search domains (as text) to the Interface.DNS field, but the GL.iNet interface only lets you add numeric values, limiting you to adding only DNS servers.