With the vanilla/standard Wireguard app, Mullvad does not hijack any DNS requests on port 53. It honors the “DNS=…” setting from the Wireguard config. All hijacking is done on the client side by the official Mullvad apps.
I just verified this on Android and was able to use Quad9 (9.9.9.9) as my DNS.
Thus, the GL-iNet firmware either fails to read the “DNS=…” setting, or it hijacks DNS itself.
No matter which DNS of profile on PC I change to, Mullvad VPN will hijack my UDP DNS. Some DNS server hijacking and some are no problem on Android.
Please confirm it with www.dnsleaktest.com or ipleak.net to check the DNS provider that your device is using.
Modify to Quad9, but hijacks
Modify to Google, but hijacks
Modify to Cloudflare, but hijacks
Modify to Quad9, but hijacks
Modify to Google, not hijacks:
Modify to Cloudflare, not hijacks:
Modify to ADG DNS, hijacks:
GL router is similar to PC WireGuard, all UDP DNSs are hijacked.
I remind again that UDP DNS being hijacked is not scary. You can enable encrypted DNS on your GL router, so that you can use Mullvad & custom DNS server at the same time.
This is very strange. Why would it hijack only some DNS (Quad9, ADG) on Android, but not others (Google, Cloudflare)?
And why would it be different on Windows? The OS dependence suggests it is a client side thing?
And as mentioned, Quad9 was NOT hijacked on my Android.
Just tested again on Android.
No hijacking.
I guess it might also be related to the Mullvad VPN server or client platform, but it won't affect anything.
And this was not DNS leaked, but was DNS hijacked or followed profile DNS.
The reason why we started this whole discussion is because people wanted to use Mullvad’s alternative ad-block/malware-block DNS servers.
See here: GitHub - mullvad/dns-blocklists: Lists and configuration for our DNS blocking service
I had a discussion with GL-iNet & Mullvad when I first encountered DNS issues with Mullvad & an AX1800 back early this year, so I reached out yesterday to the tech I was speaking to at Mullvad. FWIW, this is from the horse’s mouth:
It's true that we hijack all traffic on port 53 (DNS) by default, this
to avoid leaking any DNS traffic.It's highly recommended to just use the default DNS server ( 10.64.0.1 )
which is hosted on the VPN relay that you're connected to.If you want to use a custom DNS there is a community writeup that helps
you configure this,
Use Custom DNS Servers With Mullvad And Any WireGuard Client
I didn’t ask what we were supposed to do if we wanted to choose between Mullvad DNS servers; possibly, the answer is in the link he provided.
Did they say whether that’s client or server/network side hijacking?
He did not; I pasted his entire reply. I told him the context, though, and it was in a thread where I had been trying to figure out DNS resolution issues with an AX1800 running Wireguard via Mullvad.
Mullvad tech support is pretty good; if you're a client and have specific questions, they'll probably answer them.
Mullvad's said some upstream primaries block Mullvad's servers’ secondary queries: some domains simply don't resolve - I think that, and the DNS hijacking, are fairly obscure and the root source of many issues; none of which are caused by anything in the router, though.
Edit: note that the post of the link he provided claims Mullvad hijacks all DNS queries made over Wireguard tunnels. The client that set up the tunnel is irrelevant. You can set up a tunnel and tell Mullvad you do not want DNS hijacking; I'm not sure if this is possible through the Mullvad app, so the comment “the client is irrelevant” is probably not strictly true: if you want to disable DNS hijacking you may have to create the connection outside of the Mullvad app. Instructions are in the linked blog in my earlier comment.
Could you by any chance follow up with them and ask if any of the hijacking is done on the server side?
I thought it was 100% client side, but then it’s difficult to explain @bruce’s result … I’m wondering if he’s seeing these results because of bugs in the Windows Wireguard client (I read the DNS setting can be glitchy on Windows), or because Mullvad is actually doing hijacking on the server/network side.
@bruce I’m starting to wonder whether the issue is that the udp dport 53 return rule in ROUTE_POLICY prevents DNS queries from getting VPN marks, so when they reach dns_dispatcher, they have no marks and can't be redirected to the correct dnsmasq instance?
root@GL-MT6000:~# nft -a list table inet vpn_table | grep -A 5 -B 5 "TUNNEL5693_ROUTE_POLICY"
chain ROUTE_POLICY { # handle 5
ct mark & 0x0000f000 != 0x00000000 jump mark_ct_to_meta # handle 27
udp dport 53 counter packets 0 bytes 0 return # handle 28
jump TUNNEL8483_ROUTE_POLICY # handle 40
jump TUNNEL5693_ROUTE_POLICY # handle 45
jump TUNNEL598_ROUTE_POLICY # handle 47
jump TUNNEL10_ROUTE_POLICY # handle 49
}
[...]
Hello,
After R&D team investigation, we found that:
There are 2 APIs of Mullvad's key synchronization, one for standard Wireguard, and the other for its own Mullvad App to use.
The GL firmware installed the standard Wireguard program, that is, generated/downloaded from the Mullvad official website, or logged in with GL GUI using account, it is to use the standard API, and the Mullvad server will always hijack DNS.
Any customize UDP DNS will not take effect.
(Encrypted DNS takes effect)
The Mullvad App's API (own one) has a specified parameter. It can adjust that parameters to let the customize DNS of Mullvad App side can not be hijacked (customize DNS takes effect).