Wireguard client not honoring DNS setting [workaround discovered]

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.

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?