Mullvad Wireguard with Mullvad Adblock dns

Mullvad Wireguard connecting fine but when modifying the config DNS to use one of Mullvad Adblock dns servers results in no internet connectivity.

Using the same config and dns server in Wireguard app on iOS and internet connectivity is fine with Adblock.

This link provides the dns servers to use.

I am using the beryl travel router and have also updated to the latest 3.211 beta (also didn’t work on 3.203 stable).

I am using the Gl.iNet iOS app to connect to multiple Mullvad Wireguard servers across different locations. Default dns server works fine but as soon as I modify the dns per the above url there in no internet connectivity. I thought that maybe that it just won’t work, but applying the Adblock dns server on Wireguard iOS app manual config works with no issues. Appears that the issue is isolated to the beryl or glinet devices.

Can you change the DNS here? You need to change each profile though.

That is exactly where I am changing the dns. The default 193.x.x.x dns server is fine. As soon as I change it to Mullvad’s Adblock dns server, no pages load.

Use the same config but on iOS wireguard app and change the dns there in the config works without a problem.

Is it working for you when you change the dns there?

I just checked by myself on MT1300 3.211 beta4.

Changed DNS, Wireguard connect normal and website works normal.

Tried change DNS

For default DNS
image

For 100.64.0.1
image

For 100.64.0.2
image

For 100.64.0.3
image

So seems it is working.

BTW: If you have any custom DNS settings in more settings->custom DNS server, you should disable it because it will take priority.

Thanks for testing that. I have the same beta installed and yet after trying again it still doesn’t work. I ssh’d into the beryl and executed a dig lookup on any url and the command just times out.

I might have to flash the router cos I dunno what else to try. I have no custom dns settings and only enable vpn policy while connected to the vpn. But also tried with vpn policy disabled but still the same issue.

Can you check if your pc has DNS setup?

For example, if you are using windows 10/11, when put 8.8.8.8 and 8.8.4.4 in the dns settings, windows automatically use encrypted DNS so the rotuer have no control.

Pls check using dnsleaktest.com to check the actual dns you are using.

I only have iOS devices (iPad and iPhone) and Nintendo Switch (all impacted) while I am currently travelling. DNS is set to automatic in iOS and is just applying the dns from dhcp which is 192.168.8.1

dns leak test with JP2 Mullvad wireguard using default DNS

And same server but with dns changed to 100.64.0.3 but dns leak test does not perform the checks and other websites do not load.

For some reason you have DNS leak, meaning that the wireguard dns is not applied.

I don’t know how this happened.

Weird. I just reinstalled beta 4 without keeping any settings (assuming this resets settings to default). Re-added mullvad profile and changed the dns server. Still same issue.

Thanks for helping. I think I’m gonna give up on it.

I finally figured this out and it only just occurred to me what potentially is causing this issue. Refer to screenshots further below. The IP address/netmask conflict with Mullvad DNS Adblock ip addresses.

To overcome I created a static address but changed the netmask to 255.255.255.0 so that the Mullvad dns addresses don’t fall in the usable range.

Question is. Once the Wireguard tunnel is up shouldn’t all network traffic go through the tunnel including the dns traffic? Are there any rules or settings I can override in luci so that I can workaround this other than reconfiguring lan to static address (static not ideal may just create problems later on).

Before with dhcp assigned address. Mullvad DNS’s 100.64.0.x do not work:

After with static assigned address with modified netmask to exclude the Mullvad adblock dns range. Internet/pages now load:

Nice find.

Yes once vpn is established, all data including dns request will go via the vpn.

But the IP conflict could break settings in the router’s set, causing unknown issues. Just avoid it.