VPN DNS leak test | Hacker News Reader

VPN DNS leak test

dnsleaktest.com

161 pointsfanf244 comments

Why is a software VPN so difficult to get right? Why are so many of them so poor, or miss certain protocols, or have so many leaks?

Casting aside actual "vulnerabilities" (like buffer overflows, bad encryption, etc...), why can't a software VPN act just like a hardware VPN? Take every byte of traffic sent to a network device, and tunnel it to another endpoint?

I'm assuming there are several major reasons that I don't know about that makes what seems like a really trivial problem super difficult...

Software VPN managing all routes is perfectly fine to network traffic.

The network traffic is totally taken.

The problem here is OTHER SOFTWARE running on the computer that also has visibility into the OS. For example, browsers with p2p connections will enumerate all network interfaces - including your actual adapter's IP

Yes, and neither routing nor firewall rules will prevent that.

The simplest solution is working in VMs, with a VPN client running in the host. VMs have only virtual/internal and VPN IPs, so there's nothing sensitive to leak. Or you can use pfSense VMs as VPN gateways. Indeed, you can use a few of them, to create nested VPN chains. Also Whonix, for Tor connectivity.

> Take every byte of traffic sent to a network device, and tunnel it to another endpoint?

You have to set up routing tables to decide which interface to use for which destination address. Obviously you can't direct VPN packets via VPN - that would be circular. They have to use your normal, physical connection to get to your default gateway. But what if your default gateway is also a local DNS server? You can't differentiate protocols in routing table.

Hardware VPN have it easier - they already know which packets to tunnel because it has designated hardware port for internal network.

Interesting. So from yours and the other comment, it sounds like the issue really comes down to not being able to force all applications to use the "VPN interface", while still keeping the "hardware interface" functional so the VPN itself can use it.

I can see why it can so quickly become a giant mess...

Assuming it's the OS that needs to "fix" this, are there any changes either already made or in the works to better address this use case, or is a hardware VPN still going to be the only "real" way to securely tunnel a system for the foreseeable future?

It's less that, it's more the fact that you're presenting a standard network connection.

Software can do the equivalent of ifconfig | grep addr, software can print the routing table (and therefore get all gateways)

A really basic thing to do would just be to drop all traffic not destined toward your VPN endpoint, so leaks would fail and/or be logged, but this still doesn't solve the fact that _other software running on your computer can enumerate all your interfaces for IPs and MAC addrs and gateways_

If you do it one layer up, you solve the software problem. Software and software on generally on same layer, so equally access, at least in usual conditions

You can use custom kernel filter on Windows and iptables/netfilter on Linux to allow only one process to access physical interface. I've seen Cisco VPN Client (10 years ago or so) do it - apart from CVPND service, all traffic to/from ethernet was dropped. That included kernel stuff - to the point your PC didn't even respond to ARP packets from anything other than gateway.

Of course, introducing custom kernel driver and/or your own mini IP stack is way harder to do in a safe way - that's why it's not usually included.

As for Linux solutions - I haven't seen VPN client that used this technique, but I guess it's a lot easier, since all the required userland tools are already there.

It does not even have to be that difficult these days.

Create VPN, spin up network namespace, move tunnel interface to network namespace, start resolver in that namespace, start VPN'ed applications in that namespace. if-up scripts for OpenVPN can do this for you[0].

As long as you operate the tunnel interface and the genuine network interface side by side some applications may simply decide to ignore default routes and explicitly bind to specific network interface. There are valid reasons to do so. For proper isolation you need to hide all the non-VPN interfaces.

[0] https://www.synkretie.net/writings/easy%20namespaced%20openv...

I was recently exploring this case, where you accurately isolate particular applications to using a VPN. The best guide I found was this one (https://coldfix.eu/2017/01/29/vpn-box/) which goes into more depth and looks at alternative approaches as well.

"Software VPN" such as OpenVPN has two main use cases fighting each other.

The usage you mention is the roadwarrior, where the physical network is untrusted and you want to route all traffic through the server. This is what commercial VPN providers provide.

The other use case is routing a set of domains though the tunnel, since the local network is trusted. This is useful when you are at home with your personal computer and want to access the work's LAN, but still want YouTube or large traffic to keep going through the local network. Since you are not exclusively bound to an uplink, you can have multiple VPN of this type connected that "expose" different sets of domains. This is possible if you dig through docs, since everyone and their mother are trying to do the other kind.

And this issue could be easily overcome if more projects implemented the "socks5h://" protocol (note the 'h'), initially introduced by curl[1] to mandate the SOCKS proxy to also tunnel DNS requests. Sadly it seems that very few programs recognize this (non-standard) protocol: git[2] (using curl), python's request (and urllib) module[3] ... And not much else.

[1]: https://curl.haxx.se/docs/manpage.html#--proxy [2]: https://github.com/git/git/blob/20fed7cad40ed0b96232feb82812... [3]: http://docs.python-requests.org/en/master/user/advanced/#soc...

Firefox over a SOCKS5 proxy done with ssh passes this test if you enable the proxy DNS setting. Creating the proxy is as simple as:

  ssh -D 9999 -q -N <your ssh server>

and then configure that in the firefox proxy settings (socks to localhost:9999). If you want a simple way to enable/disable this in firefox I built a minimal extension to do it:

https://addons.mozilla.org/en-US/firefox/addon/proxyswitcher...

The defaults in the config already match that ssh line so all you need to do is press the globe button to enable the proxy.

You might be the right person to ask:

When I tried shadowsocks and enabled "proxy dns" in Firefox, every website became painfully slow. Is this simply because no DNS cache had been built?

Don't know but note that shadowsocks is not a traditional socks proxy. If I understood it correctly you do a traditional socks proxy to localhost and then a more heavily encrypted link to the actual host. Maybe that second link was slow, either because of the encryption or because it's written in python? ssh gives you as much or more security anyway as there are few protocols as thoroughly checked than ssh and performance seems nice.

Huh? VPNs aren't SOCKS proxies.

It would appear that Firefox's built-in SOCKS support successfully proxies DNS as well, though I've always wondered whether or not there aren't other ways to leak your IP via browser APIs. I imagine that Flash almost certainly would, and I wouldn't be surprised if WebRTC does somehow.

Yeah, but you have to set "socks_remote_dns" to "True" in about:config, which is not the default.

At least in Firefox 52 ESR there's UI to enable that (so no need to fiddle with about:config):

Edit → Preferences → Network → Settings → Proxy DNS when using Socks v5

But yeah, it's not the default. :\

I'm really really interested to find out how they're discovering the DNS server IP addresses I'm using.

The only clue I have is that they're trying to resolve a bunch of fake domain names (which show up as unresolveable in the console).

The webpage has the IP addresses written directly into it (so clearly the data came from the server) which means there's nothing I can investigate (eg, in JS) from my end.

What's going on?

"The DNS leak test works by sending your client a series of domain names to resolve within a specific test domain. Each request is sent from your client to your configured DNS server. Even if you have configured a single DNS server, there may be many other servers that the request is passed on to in order to be resolved (normally to load balance the requests). For example if you configure Google DNS then you will often find 6-10 Google DNS servers which are fullfilling the DNS requests."

via https://www.dnsleaktest.com/what-is-the-difference.html

Basically it's sending you unique subdomains and then in turn seeing what IP addresses DNS requests come from. Since the subdomains are tied to you, it can tie the requests from the DNS servers you're using back to you.

friendly reminder not to use google DNS if you care about privacy (which you probably do if you're using a VPN in the first place), because you're basically giving them your fingerprint in the form of the websites you visit.

Hmmmm.

Google has ~7ms response time for me though. Even my ISP's nameservers are slower than that :( the average everywhere else is 200ms (yup).

My internet is slow enough that this makes it a tiny bit more annoying.

But you make a very valid point, and... sigh convenience is such an hacked catalyst nowadays :(

https://developers.google.com/speed/public-dns/privacy

Unless you're the tinfoil-hat wearing type who believes they're lying, their privacy policy looks pretty good to me.

OH, nice one. I knew the random hostname was part of the puzzle, but couldn't quite get that far. Thanks for the concise explanation :)

Be carful here. You might not see the IP you expected even if everything is fine. BGP anycast and other load balancing technologies can make it look like the wrong IP. Make sure the IP is owned by the service you expect vs. being the exact IP you have configured.

Crap, failed on my home road-warrior setup. Now I have to go figure out which OpenVPN config settings to change to forward DNS better.

See `--dhcp-option` (https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage)

There is a page on the site that can help you with this https://www.dnsleaktest.com/how-to-fix-a-dns-leak.html

This is also a handy way to see if your outbound DNS requests are being hijacked and sent to another resolver instead of your chosen ones. One router I tested redirected everything to OpenDNS if parental controls were in use, some networks redirect everything to their internal resolvers, etc. Mainly for interest purposes/spotting configuration mistakes than anything else.

There's a page about transparent DNS proxies [0] on the same site. They also have a page about how to fix dns leaks when using OpenVPN [1].

One way to ensure that DNS responses have not been tampered with is to use DNSCrypt [2].

Can someone confirm that I understand this correctly : if I don't use DNSCrypt and if my DNS responses are tampered with in a phishing attempt, on a site that uses https, the browser will raise a cert error since the attacker won't have a valid certificate. So phishing attempts by spoofing DNS responses are only effective when the site uses plain http.

[0] https://www.dnsleaktest.com/what-is-transparent-dns-proxy.ht...

[1] https://www.dnsleaktest.com/how-to-fix-a-dns-leak.html

[2] https://dnscrypt.org/

Not just http, any unencrypted channel is vulnerable to this. So SMTP or pop without encryption would also let someone into your email.

It makes sense to me to always configure your firewall alongside your VPN. If you are under the impression that all traffic on your system is routed via your vpn, you can state that explicitly in your firewall. If things still work, it must be true :)

The test works fine on my iPhone but as soon as I try it on my PC connected through Viscosity it's stuck seemlingly forever. I killed it after a few minutes. Upon disconnecting it's all good and fast. What could I be doing wrong here?

https://ipleak.net Is similar, but has some useful additional diagnostics.

There's a lot of talk about various services being vulnerable to dns leak tests or not. Which I think is slightly funny, since you're WAY more likely to suffer data leaks via the innumerable ways your browser can do it.

For what it's worth though, a modern openvpn configuration can beat it handily. An example of a service that passes with flying colors is ProtonVPN, which I just checked last night since they've got a crazy discount going right now.

Pardon my ignorance, but do DNS leaks impact Tor anonymity or are we strictly talking VPNs?

ipvanish is good if anyone else is wondering

Just tested my Ipvanish and yes it looks fine except some servers eg when connected to Singapore, say Costa Mesa USA (i'm in Australia).

VPN is not supposed to hide you, it just provides access to some resources that are not available without VPN.

Well, not always or not always like that. For example, I use VPN so I can achieve my true download speed when downloading from Steam, since my ISP limits to download speed in that case.

Which country, which ISP, please?

I'm not OP, but the same thing happens to me - UK, Virgin Media, even on their highest tier truly unlimited 200mbps bundle. Steam will start downloading at close to 20MB/s and then slow down after 10-15 minutes. When connected via VPN it runs at full speed all the time.

Similar speeds here but works differently. Mine just gets throttled to ~2.5MB/s from start until I turn my VPN on, then I get my correct 20MB/s.

Spain, Jazztel

Reply on news.ycombinator.com