There are a few domains that won't resolve when the VPN is up. I'm running dnsmasq on the router.
I've spoken to Mullvad support, who says the primaries for these domains are rejecting requests from their DNS servers; this would explain the inability to resolve domains through Mullvad's DNS servers. However there are a couple of other oddities:
Mullvad doesn't recognize the DNS server that the AX1800 claims that it is getting "from Wireguard" (193.138.219.228) and, indeed, it's not one of their servers. Question 1: Where is this coming from?
If I log into the router, I can resolve the addresses using nslookup on the AX1800; it gives me two responses -- the IP address, and an error. I assume the IP address is coming from the secondary DNS servers that the AX1800 is getting from the ethernet provider (Comcast, in my case) -- "DNS from ethernet" are 75.75.75.75 and 75.75.76.76 -- although if I try to query those directly from my computer, I get failures. So, question 2 is: if the router can resolve the domains, why isn't it providing those addresses to connected clients?
Would someone else who's using Wireguard with Mullvad and automatic DNS configuration check these domains and see if they can resolve them?
In default, GL firmware does not intercept filtering the ort 53 DNS requests.
Instead, if Mullvad VPN is enabled, the Mullvad will listen to all 53 DNS traffic, and all DNS request traffic will through Mullvad DNS.
If the Mullvad DNS unable to resolve the domains, so the VPN client cannot access these resource.
If you want to avoid intercepting DNS from Mullvad, you can use the GL GUI> NETWORK > DNS > choose the Encrypt DNS.
Instead, if Mullvad VPN is enabled, the Mullvad will listen to all 53 DNS
traffic, and all DNS request traffic will through Mullvad DNS.
If the Mullvad DNS unable to resolve the domains, so the VPN client cannot access these resource.
I've been speaking with Mullvad support. They confirm some upstream DNS servers
reject their 2nd level DNS queries, so that's probably the root of the problem. However, he also said:
From Stefan @ Mullvad:
My colleague found out that we used 193.138.219.228 as a DNS address
more than five years ago, but it's not in use anymore.
Are the DNS routers for the built-in VPN providers hard-coded in the GL-iNet
firmware? Where do the routers get the DNS information for a given VPN provider?
The current DNS routers for Mullvad are 194.242.2.2 and 194.242.2.3; I bought
this router after Mullvad stopped using 193.138.219.228 as a DNS server, yet you
can see that the router is claiming that's the IP of the
DNS server that it got "from Wireguard":
Please check the VPN profile DNS = x.x.x.x from the WireGuard client, our SDK code will not have hardcoded using this DNS, this DNS address probably comes from the VPN profile.
Please check the VPN profile DNS = x.x.x.x from the WireGuard client, our
SDK code will not have hardcoded using this DNS, this DNS address probably
comes from the VPN profile.
I've also been talking to Stefan at Mullvad, and he says that's an old name
server they do not use any more, and would not be providing in their
configurations. Specifically, Stefan says:
Another user with a GL.iNet Beryl router contacted us and said that it
looks like it is defaulting to 193.138.219.228 under the DNS section also.
I am almost certain that the DNS is not coming from our API. Could they
check with a developer to make sure that they did not hardcode it?
I've looked everywhere I can think of in the GUI, and can't find that DNS
setting; I've got it set to "DNS from Wireguard" and see no place in the
Wireguard configuration where this would be set. Could you point me to where I
should look?
My list of exit nodes was populated with the "Refresh Servers" function, so the configurations were generated -- they aren't something I edited. Supposedly, either the router is calling a Mullvad API to get each of these configurations, or is calling an API to get a list of exit nodes, and is generating the configurations.
Which Mullvad API is being called to generate these configurations? If you could let me know which Mullvad service is being called, then we could identify where this DNS setting is coming from. For exampe, if the router is calling a Mullvad API that's providing full wg-quick configurations with the DNS server in them, then I can pass that information along to the Mullvad tech and they can track it down on their side.
Double checked the SDK code, confirm the DNS 193.138.219.228 has hard code to fixed value. It has nothing to do with the API. Sorry about this.
However, no matter what DNS the router uses, as long as it is connected to Mullvad VPN, Mullvad will redirect DNS 53 traffic to Mullvad own DNS and then resolve the domain.
For the hard code DNS (193.138.219.228), the PM team will evaluate whether it is removed. Thanks.
I found that MullVAD used 192.138.219.228 for DNS prior to Feb 2019. As of March 2019 they stopped using it and moved to an new DNS server IP. This article "Our public DNS is changing Mullvad VPN https://mullvad.net › blog › our-public-dns-changing" shows the new IP and says those on WG need to make the changes to their configuration. I just started running into this today myself, even with custom DNS servers and everything configured my whole network is trying to use the OLD ip of the DNS server to resolve. I have Mullvad with per device policy set and only 2 MAC's set in the policy. This breaks the entire network anytime mullvad is enabled now.
For WireGuard clients, the DNS IP doesn't matter, mullvad will automatically handles all DNS traffic inside the tunnel.
You can ignore the old DNS address.
If you want to change dns server for test:
sed -i "s/option dns '193.138.219.228'/option dns '10.64.0.1'/g" /etc/config/wireguard
ifup wgclient
I don’t think this is right. Mullvad works with any DNS server. DNS can be configured in the app. I assume the equivalent in the stock wireguard client is the DNS=… setting.
EDIT: I just tested and saw that my Flint 2 indeed ignores the DNS=… setting in my Mullvad wireguard profiles. However, I think that this is a Flint issue, not a Mullvad/Wireguard limitation.
I'd think the quickest way to confirm that would be to set the conf with DNS = 9.9.9.9. Then check the connection against Quad9's test page/service. If 'no' I'd think Mullvad is successfully intercepting DNS:53. It should be the same result if using a more 'standard' WG client, say, on a phone. That's just off the top of my head.
I already did this, and it shows the Mullvad DNS. However, I suspect it’s the Flint intercepting/hijacking the DNS request (or simply ignoring the config in the first place), not the Mullvad network. Because Mullvad does support custom DNS servers.
Here is what happens when I set my custom DNS to Quad9 in the Mullvad App:
Well, the default DNS:53 is provided by the dnsmasq daemon. You can see what it has as its default upstream @ grep 'nameserver' /tmp/resolv.conf.d/resolv.conf.auto. Whether the GL customization scripts do anything to a DNS request when wrapped in a VPN tunnel IDK but if you suspect DNS:53 is being intercepted by the Flint v2 itself before hitting the WAN I'd run tcpdump on a device upstream & see what turns up while running in cleartext.
If you get the same results when using a phone & a WG client other than the Mullvad one then you can safely rule out the Flint v2.
You are using the Mullvad VPN APP on your phone instead of the official standard WireGuard APP.
On GL routers, the WireGuard client and server are official standard version.
To control variables for comparison, you should install the standard WireGuard APP on your PC/phone and modify the DNS of the Mullvad profile, so that can verify whether Mullvad VPN hijacks UDP DNS of port 53.
