Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VPN DNS leak test

dnsleaktest.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: VPN DNS leak test

#11

Post by Klathmon »

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...

Re: VPN DNS leak test

#12

Post by kibwen »

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.

Re: VPN DNS leak test

#13

Post by dylz »

Klathmon wrote: post #11

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…

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

Re: VPN DNS leak test

#14

Post by magnat »

Klathmon wrote: post #11

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…

> 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.

Re: VPN DNS leak test

#15

Post by Klathmon »

magnat wrote: post #14
Klathmon wrote: post #11

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…

> 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 differ…

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?

Re: VPN DNS leak test

#16

Post by the8472 »

Klathmon wrote: post #11

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…

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...

Re: VPN DNS leak test

#18

Post by Skunkleton »

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 :)

Re: VPN DNS leak test

#19

Post by dylz »

Klathmon wrote: post #15
magnat wrote: post #14

Earlier quoted context omitted.

> 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 differ…

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…

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

Re: VPN DNS leak test

#20

Post by magnat »

Klathmon wrote: post #15
magnat wrote: post #14

Earlier quoted context omitted.

> 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 differ…

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…

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.

Post reply on HN