Linux Mint DNS Leak issue?

[hashswag 11]

OS: Linux Mint 17.1

Router: RT-AC68U / Tomato Shibby / manually set DNS to comodo DNS servers

ISP: Verizon FiOS

 

I am running the latest Eddie Client (2.8.8).  When running the DNS Nameserver Spoofability Test at https://www.grc.com/dns/dns.htm, I am getting 6 DNS servers listed.

 

1.  46.21.154.83 (which is the AirVPN expected DNS)

2.  178.255.84.38 (no-dns-yet.ccanet.co.uk)

3.  178.255.84.35 (no-dns-yet.ccanet.co.uk)

4.  178.255.84.37 (no-dns-yet.ccanet.co.uk)

5.  178.255.84.39 (no-dns-yet.ccanet.co.uk)

6.  178.255.84.40 (no-dns-yet.ccanet.co.uk)

 

I have tried both the DNS Switch mode of "Automatic" and "resolveconf" with no difference.  The resolv.conf file on my system looks like this:

 

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.4.0.1
nameserver 127.0.1.1
 

Other DNS Leak test sites only show one DNS entry.  I am using Firefox and have cleared all cache, cookies, etc.

 

How is it this particular leak test is finding the router-based DNS servers?

 

 

SOLVED:  As noted below, the leak was solved by setting "DNS Switch mode" to "Renaming" in the Eddie client.

[Khariz 109]

Indulge me in a dumb question? What is the problem with leaking a secure DNS? Some VPNs do this on purpose. Some set up DNS caching of say Google's public DNS on the VPN exit points so that your DNS appears to be only the IP address of the exit server. But others explicitly route DNS queries to the actual DNS servers (heck, I think AirVPN has it set up to fallback like this if the primary DNS caching fails). Those that do the latter will make your DNS leak results look the same as yours.

 

Don't get me wrong, I understand why you want to "fix" it, but as long as you aren't leaking you ISP's DNS numbers, it's technically mission accomplished (assuming you are leaking a secure DNS server like you are).

[hashswag 11]

Thanks for the response.

 

I would like to hear from AirVPN staff that this is normal and not a bug somewhere in the AirVPN Eddie client.  I have read in forums that anything other than an AirVPN DNS server is considered a leak, and Linux does not leak.  These are contradictory statements that I would like cleared up.

 

I will temporarily change to the Verizon DNS servers and see if those leak as well.

 

Update:

I reverted to the "default" DNS servers provided by my ISP.  The same test took a lot longer (perhaps the ISP DNS servers are slower?).  It resulted in 3 DNS servers found:

 

1. 46.21.154.83

2. 71.243.0.* (test indicates 16 IP addresses found in the range)

3. 68.237.161.* (test indicates 10 IP addresses found in the range)

 

The ISP DNS servers are:

71.243.0.12:53

68.237.161.12

 

So..  It's a leak.  Unless the purpose of the test isn't to detect leaks and is doing something else.  The name of the test is "DNS Nameserver Spoofability Test", not necessarily DNS Leak.  But it does come back with the DNS name servers listed in the router (in addition to the AirVPN name server).

 

I read elsewhere that ipv6 can cause leaks.  I confirmed that ipv6 is disabled on the router.  It was enabled on my Linux system, but it is now disabled and the tests still show the 6 DNS servers.

[hashswag 11]

Interesting:  I changed the DNS Switch Mode to "Renaming", and the leaks from GRC went away.

 

A test now shows 2 DNS servers:

1.  46.21.154.83

2.  54.225.156.17 (ec2-54-225-156-17.compute-1.amazonaws.com) (an airdns.org server)

 

The /etc/resolv.conf now looks like this:

# Automatically generated by AirVPN client v2.8.8 | https://airvpn.org . Any manual change will be overridden.

nameserver 10.4.0.1

 

Questions to staff:

1.  Why do I need "Renaming" when I have resolv.conf installed (I posted my resolv.conf file above)?

2.  Why do no other leak test sites show leaks besides grc.com?

 

Thanks....

[Khariz 109]

Oh, don't misunderstand me. I agree with you that it's a leak of sorts. I'm just saying that if you control the leak to only show an acceptable alternative to your non-ISP-secure-DNS, at least there's no harm. But the leak still needs to be plugged, yes.

I will agree that AirVPN, when working as designed, does not leak like you are seeing. I have no frame of reference for Linux though. I can't say what's going wrong with that client, though I figured the DNS stuff was mostly happening server side. Since it works properly for me in the windows, OS X, and ios clients, it must be some kind of Linux issue, which by the title and subject of this thread, you seem to be well aware of.

Edit: I meant to post this before your second post. Ignore me. I'll enjoy seeing what the staff says.

Okay, so I've never used that tool that you are talking about. I usually just use IPleak.net or dnsleaktest. Like you said, on those tools, I'm showing no leak.

 

Using the tool you are using, I'm getting 3 servers on OS X.  All appear to be part of AirDNS routing:  199.19.94.135 (exit server), 54.225.156.17 (AWS), 54.246.124.152 (AWS) 

 

Check out what AirVPN over iOS shows: I'm getting 3 servers. All appear to be part of AirVPN or their AWS DNS routing. See attached photo.

[rickjames 106]

I'm fairly sure that server depending air uses AWS servers for dns lookups when their servers get loaded.

 

 

@leaks

-Windows can have actual leaks. By leak I mean some malformed routing outside the tunnel.

-Linux just has less than ideal settings being used.

-I haven't used iOS in ages so tbh I'm clueless with that.

 

People have started calling using alternate dns servers leaks. When in reality if its not outside the tunnel its not a leak. Its just non optimal dns servers being used. -as Khariz said The main thing to avoid is using your isp's dns server in or out of the tunnel.

 

 

@hashswag

Your original post contained this in the resolv.conf

nameserver 127.0.1.1

It was most likely added by the 'Network Manager' with DHCP enabled. Eg. your linux machine is pulling dns info/settings from your router. -a little more info below.

 

 

"1. Why do I need "Renaming" when I have resolv.conf installed (I posted my resolv.conf file above)?"

 

-I don't use the client but it look like renaming is doing just that. Renaming the resolv.conf to something like resolv.conf.old. Then completely replacing it with air's clean version. Closing the client probably restores the old resolv.conf. Its a very compatible method to use so it would make sense.

 

-The other option is probably just adding the air nameservers into your existing resolv.conf but not removing anything "or everything" else in there. -this could also simply be an oversight in the air client not removing 127.0.1.1 / 127.0.0.1 / search.

 

"2. Why do no other leak test sites show leaks besides grc.com?"

I don't know what code ipleak is using but seemingly its less extensive.

 

Try these as well

https://www.dnsleaktest.com/

http://entropy.dns-oarc.net/test/

 

 

 

Things you could do:

-Use the renaming option. It seems to temp replace the resolv.conf with air's clean version.

-Disable all DHCP -> Use a static ip and dns setup. DHCP will try and pull its DNS and IP info from your router or what ever device is in front of your machine running a dhcp server.

-This is more of a failsafe if you're the only one on your router. -> Set the LAN DHCP Server on your router to send DNS servers 10.4.0.1/10.5.0.1 -> any dhcp device connected to the router should then receive those dns servers. However any other device will get those nameservers as well, this can be problematic unless all devices are using the vpn.

 

 

What I would do/do is a little more extreme.

-Don't use a network manager at all. Its either never installed or removed/purged.

-Manually setup static networking options via editing /etc/network/interfaces "or however its setup on your distro"

-Manually setup the recolv.conf with only nameserver 10.4.0.1 nameserver 10.5.0.1 inside it.

-Extremely strict stateful firewall based on conntrack/linux or pf/bsd-freebsd-kfreebsd

 

With no DHCP and no Network manager your resolv.conf should never change.

 

-sry for the ramble, drank a lot of coffee hah.

[Staff 9751]

Hello!

 

There are no DNS leaks on Linux since it implements and support global DNS. Linux queries only the specified nameservers and even if you have made some mistake such queries are tunneled anyway.

 

If you set in Linux your router as nameserver, and your router queries some public DNS or your ISP DNS, then the query is sent outside the tunnel by the router: again this is not a DNS leak by Linux.

 

If you use IPv6 as nameservers then the queries are sent out in IPv6 outside the IPv4 tunnel (we'll take care more and more about IPv6 soon). Again, not a Linux DNS leak.

 

The above mentioned cases anyway must not occur if DNS push by servers is accepted properly (either by direct renaming of resolv.conf or through resolvconf package).

 

Kind regards

[hashswag 11]

I'm fairly sure that server depending air uses AWS servers for dns lookups when their servers get loaded.

 

 

@leaks

-Windows can have actual leaks. By leak I mean some malformed routing outside the tunnel.

-Linux just has less than ideal settings being used.

-I haven't used iOS in ages so tbh I'm clueless with that.

 

People have started calling using alternate dns servers leaks. When in reality if its not outside the tunnel its not a leak. Its just non optimal dns servers being used. -as Khariz said The main thing to avoid is using your isp's dns server in or out of the tunnel.

 

 

@hashswag

Your original post contained this in the resolv.conf

nameserver 127.0.1.1

It was most likely added by the 'Network Manager' with DHCP enabled. Eg. your linux machine is pulling dns info/settings from your router. -a little more info below.

 

 

"1. Why do I need "Renaming" when I have resolv.conf installed (I posted my resolv.conf file above)?"

 

-I don't use the client but it look like renaming is doing just that. Renaming the resolv.conf to something like resolv.conf.old. Then completely replacing it with air's clean version. Closing the client probably restores the old resolv.conf. Its a very compatible method to use so it would make sense.

 

-The other option is probably just adding the air nameservers into your existing resolv.conf but not removing anything "or everything" else in there. -this could also simply be an oversight in the air client not removing 127.0.1.1 / 127.0.0.1 / search.

 

"2. Why do no other leak test sites show leaks besides grc.com?"

I don't know what code ipleak is using but seemingly its less extensive.

 

Try these as well

https://www.dnsleaktest.com/

http://entropy.dns-oarc.net/test/

 

 

 

Things you could do:

-Use the renaming option. It seems to temp replace the resolv.conf with air's clean version.

-Disable all DHCP -> Use a static ip and dns setup. DHCP will try and pull its DNS and IP info from your router or what ever device is in front of your machine running a dhcp server.

-This is more of a failsafe if you're the only one on your router. -> Set the LAN DHCP Server on your router to send DNS servers 10.4.0.1/10.5.0.1 -> any dhcp device connected to the router should then receive those dns servers. However any other device will get those nameservers as well, this can be problematic unless all devices are using the vpn.

 

 

What I would do/do is a little more extreme.

-Don't use a network manager at all. Its either never installed or removed/purged.

-Manually setup static networking options via editing /etc/network/interfaces "or however its setup on your distro"

-Manually setup the recolv.conf with only nameserver 10.4.0.1 nameserver 10.5.0.1 inside it.

-Extremely strict stateful firewall based on conntrack/linux or pf/bsd-freebsd-kfreebsd

 

With no DHCP and no Network manager your resolv.conf should never change.

 

-sry for the ramble, drank a lot of coffee hah.

 

Thanks for the detailed response!

 

My original resolv.conf has 127.0.1.1 in it because that's what the AirVPN client left in it.  I seriously think this is a bug in the Eddie client.  Both the "Automatic" and "resolvconf" settings leave it in there, resulting in a leak.  I call it a leak because when the VPN is up, DNS queries are going outside the tunnel. Granted, the leak is induced by what is in my opinion a bug in the AirVPN Client for Linux by leaving a nameserver in there that looks at the router.

 

Every device on my network is set up with static DHCP.  It is far easier to manage IP addresses from a central location (the router) than each device and keeping a spreadsheet of which device is which. 

 

If I manually set up resolv.conf with the AirVPN nameservers, my internet would not work when not connected to AirVPN.  Some websites don't allow connections from VPNs (my viop provider is one of them).

 

Staff, the AirVPN client should not be leaving entries in the resolv.conf file if they can induce a leak (a leak is defined by something that can get outside the tunnel when the tunnel is connected).  Perhaps leak is the wrong term.  Misconfiguration by the AirVPN client?

 

I'm glad I have this resolved (no pun intended), but *any* other Linux user who doesn't know about this setting, or don't know to test their DNS leakage using the grc.com DNS test, have a false sense of security.  The *only* reason why my original DNS leaks were going to comodo was because I use comodo DNS servers in my router.  I'm guessing most people don't use specific DNS servers, and if they don't, the default AirVPN Eddie client settings will leak to the ISP DNS servers..  I highly suggest updating the documentation or wiki to include the grc.com DNS test to avoid DNS "leaks" to ISP DNS servers.

 

Thanks...

[rickjames 106]

hashswag, on 12 Mar 2015 - 11:01, said:

My original resolv.conf has 127.0.1.1 in it because that's what the AirVPN client left in it.  I seriously think this is a bug in the Eddie client.  Both the "Automatic" and "resolvconf" settings leave it in there, resulting in a leak.

 

 

 

I think you're correct.

However without seeing your exact routing its hard to know if its in or out of the tunnel. Generally Its still in the tunnel on linux but your connection goes out via the vpn then back to your isp's dns. Either way its far from optimal.

 

Have you tried running jnettop to see if its the tun0 or eth0 making the connection to the dns? That would at least tell you if its in the tunnel ect.

 

I guess the simplest solution would be to have the default option in the client always replace the file if resolv is installed.