Mullvad intercepts DNS packets

NaDre

I recently decided to try out Mulvad.

I run my own DNS server - Unbound. So my Unbound instance will make direct queries to root name servers. When I have the VPN running, these queries will go over the VPN.

Well, they go over the VPN to the root server when I use AirVPN. They do not when I use Mulvad. They get redirected to a Mulvad DNS server.

If you have Mulvad, you can easily check this yourself. First here is a list of the root name servers for .com:

$ dig com ns

; <<>> DiG 9.11.9 <<>> com ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61487
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;com.                           IN      NS

;; ANSWER SECTION:
com.                    86400   IN      NS      d.gtld-servers.net.
com.                    86400   IN      NS      c.gtld-servers.net.
com.                    86400   IN      NS      e.gtld-servers.net.
com.                    86400   IN      NS      i.gtld-servers.net.
com.                    86400   IN      NS      b.gtld-servers.net.
com.                    86400   IN      NS      l.gtld-servers.net.
com.                    86400   IN      NS      h.gtld-servers.net.
com.                    86400   IN      NS      k.gtld-servers.net.
com.                    86400   IN      NS      g.gtld-servers.net.
com.                    86400   IN      NS      f.gtld-servers.net.
com.                    86400   IN      NS      j.gtld-servers.net.
com.                    86400   IN      NS      m.gtld-servers.net.
com.                    86400   IN      NS      a.gtld-servers.net.

;; Query time: 137 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 29 10:10:00 MDT 2020
;; MSG SIZE  rcvd: 256

Then with the VPN off you can do this:

$ dig @d.gtld-servers.net google.com

; <<>> DiG 9.11.9 <<>> @d.gtld-servers.net google.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19136
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      A

;; AUTHORITY SECTION:
google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.         172800  IN      AAAA    2001:4860:4802:34::a
ns2.google.com.         172800  IN      A       216.239.34.10
ns1.google.com.         172800  IN      AAAA    2001:4860:4802:32::a
ns1.google.com.         172800  IN      A       216.239.32.10
ns3.google.com.         172800  IN      AAAA    2001:4860:4802:36::a
ns3.google.com.         172800  IN      A       216.239.36.10
ns4.google.com.         172800  IN      AAAA    2001:4860:4802:38::a
ns4.google.com.         172800  IN      A       216.239.38.10

;; Query time: 87 msec
;; SERVER: 2001:500:856e::30#53(2001:500:856e::30)
;; WHEN: Wed Jul 29 10:11:20 MDT 2020
;; MSG SIZE  rcvd: 287

Note the line about "recursion requested but not available" and that it does not give an address for google.co. Just information about its name servers. with their addresses.

Now with Mulvad on:

$ dig @d.gtld-servers.net google.com

; <<>> DiG 9.11.9 <<>> @d.gtld-servers.net google.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40207
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a5a686d10c9e59acb0c5581f5f219fe13f06ab16ec7c293d (good)
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             159     IN      A       172.217.168.238

;; AUTHORITY SECTION:
google.com.             42500   IN      NS      ns1.google.com.
google.com.             42500   IN      NS      ns4.google.com.
google.com.             42500   IN      NS      ns2.google.com.
google.com.             42500   IN      NS      ns3.google.com.

;; Query time: 149 msec
;; SERVER: 192.31.80.30#53(192.31.80.30)
;; WHEN: Wed Jul 29 10:12:13 MDT 2020
;; MSG SIZE  rcvd: 155

It has done the recursion and provided the address for google.com. No "additional" section with glue information for name servers.

This last response was not from a root name server.

Others have also encountered this:

https://www.reddit.com/r/WireGuard/comments/f15g5i/mullvad_prevents_using_custom_dns

https://news.ycombinator.com/item?id=17095618

I would say this is extremely poor judgement. Even if it is not being done for malicious reasons. This is a "DNS man in the middle".

EDIT:

You can do this test on Windows too. With the VPN off:

C:\???>nslookup google.com d.gtld-servers.net
(root)  nameserver = h.root-servers.net
(root)  nameserver = i.root-servers.net
(root)  nameserver = j.root-servers.net
(root)  nameserver = k.root-servers.net
(root)  nameserver = l.root-servers.net
(root)  nameserver = m.root-servers.net
(root)  nameserver = a.root-servers.net
(root)  nameserver = b.root-servers.net
(root)  nameserver = c.root-servers.net
(root)  nameserver = d.root-servers.net
(root)  nameserver = e.root-servers.net
(root)  nameserver = f.root-servers.net
(root)  nameserver = g.root-servers.net
Server:  UnKnown
Address:  2001:500:856e::30

Name:    google.com
Served by:
- ns2.google.com
          2001:4860:4802:34::a
          216.239.34.10
          google.com
- ns1.google.com
          2001:4860:4802:32::a
          216.239.32.10
          google.com
- ns3.google.com
          2001:4860:4802:36::a
          216.239.36.10
          google.com
- ns4.google.com
          2001:4860:4802:38::a
          216.239.38.10
          google.com

With Mulvad on:

C:\???>nslookup google.com d.gtld-servers.net
Server:  d.gtld-servers.net
Address:  192.31.80.30

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:400e:80d::200e
          172.217.168.238

go558a83nk

have you tested any other vpn?

NaDre

Just AirVPN.

I am not unhappy with AirVPN. I was just curious how Mulvad had set up Wireguard. Tried to do my normal stuff and hit this.

If they had malicious intent, they could have made the response from their DNS server look like a root server. So I chalk this up to "the road to hell is paved with good intentions".

OpenSourcerer

They mention this themselves, so this shouldn't be news if any of these ladies/gentlemen in the links you quoted actually RTFM.

Quote

It's worth noting that all our VPN servers hijack calls to our public DNS server and that the DNS requests are processed on a local non-logging DNS server installed on that VPN server. This is done to process requests faster and to leak less information to the internet.

I tried their app for Linux and you can enter your own DNS servers there, or choose to not alter them at all, and that worked. So I can't reproduce Reddit poster's findings. But to be fair, I tried v2020.05 and he/she was on an older version. Things could've changed.
Only nuisance was that right after launch the app connected itself and set Mullvad's DNS servers without asking.

NaDre

42 minutes ago, giganerd said:

They mention this themselves, ..

Perhaps they should explain some of the limitations this will cause, and put this notice in a much more prominent location?

I say this because this is not "net neutrality". Should that not be the default starting point?

If your ISP did this (to "protect" you) would that be reasonable? Or would that be "ISP spying"?

I did not attempt to read every page on their site before I tried using it. I doubt that many people would. Also, when did they add that single paragraph in an obscure location? After they received several complaints? I would say that this was not an adequate response.

OpenSourcerer

5 minutes ago, NaDre said:

Perhaps they should explain some of the limitations this will cause, and put this notice in a much more prominent location?

And what are the limitations in your eyes? As long as DNS requests are resolved correctly and not poisoned, it's okay. It'd create a giant backlash on the internet if they started playing with the results.

8 minutes ago, NaDre said:

I say this because this is not "net neutrality". Should that not be the default starting point?

I fail to see how this is an argument against net neutrality. There is a certain potential, I agree, but your link does not talk about potential. So I'd say, innocent until proven otherwise.

13 minutes ago, NaDre said:

I did not attempt to read every page on their site before I tried using it. I doubt that many people would. Also, when did they add that single paragraph in an obscure location? After they received several complaints? I would say that this was not an adequate response.

Why don't we ask some web archives? It was there as early as October 2019. So while the Hacker News thread was indeed in 2018, the Reddit user posted the "news" while the paragraph was indeed there. Those "several complaints" must have happened between May 2018 and mid-2019, if at all.

I'm not trying to discredit you. If you feel it's unfair what they're doing, don't use or recommend them, but you know this. I guess, you may proof with a 1000 good deeds that you're worth something, but it still only takes one mistake to proof you're not.

NaDre

1 hour ago, giganerd said:

... As long as DNS requests are resolved correctly and not poisoned, ...

My query to a root DNS server did not return what that root server would have returned. My DNS request was not resolved.

I could not use custom DNS with SQUID over the VPN. That is the limitation I hit. I don't let the VPN be my default gateway. That requires too much trust in my VPN provider. Using SQUID bound to the VPN I can browse over the VPN without having the VPN as the default gateway. There are many processes running in Windows that I do not want using the VPN.

One of those links talked about another limitation. You expect me to write an essay?

The wikipedia page I linked says " With net neutrality, ISPs may not intentionally block, ...". My packet was blocked.

The definition of net neutrality is pretty clear. I think many people use VPNs because they think that their ISP is not respecting net neutrality and are interfering with traffic. So wouldn't they want to know if their VPN provider is doing exactly that?

EDIT:

On AirVPN's home page it says "A VPN based on OpenVPN and operated by activists and hacktivists in defence of net neutrality ...", So it seems that AirVPN places some importance on respecting net neutrality.

Air4141841

I have the same results with Pfsense and Mullvad. I decided to subscribe for another 6 months after said I wouldn't

each tunnel using their testing tool it shows their DNS.

1. I have used the steps here under DNS leak protection 1. https://www.techhelpguides.com/2017/06/12/ultimate-pfsense-openvpn-guide/. where it forces alternate DNS. and it still shows DNS>. this method works using Airvpn tunnels and other provider tunnels
2. under services > DHCP server >. device >. I plug in static ALTERNATE dns servers. and it still shows it using Mullvad DNS.

I read somewhere you can use a push DHCP dns command or similar to change the DNS servers. if I get time I may look at doing that again. but I am seeing what the OP is stating as well

Staff

@NaDre

Hello!

So, out of curiosity, if you need your own DNS to resolve names in some specific "namespace" that's not ICANN's (OpenNIC and Namecoin come to mind, for example) you can't do it?

If you need to tunnel traffic in a custom protocol over DNS queries to some service (different than a DNS server) to port 53 you are unable to reach it because that traffic is hijacked to some Mullvad DNS server?

Kind regards

NaDre

1 minute ago, Staff said:

@NaDre

Hello!

So, out of curiosity, if you need your own DNS to resolve names in some specific "namespace" that's not ICANN's (OpenNIC and Namecoin come to mind, for example) you can't do it?

If you need to tunnel traffic in a custom protocol over DNS queries to some service (different than a DNS server) to port 53 you are unable to reach it because that traffic is hijacked to some Mullvad DNS server?

Kind regards

So far as I can tell, all UDP packets for port 53 get redirected. One of the links above quotes a response from their support:

https://news.ycombinator.com/item?id=17095618

"We added iptables rules to hijack all DNS requests on port 53 going via the VPN tunnel, this is to protect users having set a DNS server unknowingly (or by malware). We are aware that not all users want this behaviour, and we intend to add an extra port that OpenVPN listens on, where DNS hijacking will not happen. "

I don't think they ever set up a way to avoid this.

Staff

@NaDre

Thanks, very interesting information for everyone.

Kind regards

GeorgeTheSecond

This is explained in the FAQ, or you could drop a mail to Mullvad support.

Just connect to 1400 UDP or 1401 TCP and there is no DNS highjacking.

I use both AirVPN and Mullvad. Both are great, reliable and technically skilled providers with a good reputation.

https://mullvad.net/nl/help/search/?q=1400

Edited ... by GeorgeTheSecond
Added link to faq

Mullvad intercepts DNS packets

Recommended Posts

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

Share this post

Link to post

Share this post

Link to post

NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Join the conversation