DNS Leak

[Mike McCall]

I have PIA setup on my Untangle box via TunnelVPN. I've set my endpoints to call DNS from the Untangle box. However, I'm still leaking DNS to my ISP and I don't see where the leak is. What am I missing?

 

[Sky-Knight]

The obvious... But it's DNS so obvious isn't so obvious...

Untangle will use whatever DNS servers are listed on any WAN. It, just like your workstation, simply goes down the list. If you want to enforce the use of specific DNS for specific clients, or you want to enforce the use of tunnel based DNS you have to configure the system to do that.

And, because Untangle itself must have DNS independent of the tunnel, or the tunnel flat won't work, that basically means you need to modify your DHCP to hand out your VPN provider's DNS servers to your stations, and when the VPN tunnel is offline they just don't work.

We need a conditional port forward when the tunnel is down to redirect selected traffic to a specific dns server, or the same in reverse, when the tunnel is up these addresses go there... but we don't have that feature yet, and I'm not certain it would be safe to use if we did.

But yeah, this is a well trod discussion on the Untangle forums.

 

[Mike McCall]

I'll admit up front that the obvious isn't always obvious to me.

I run the VPN for everything on my network with few exceptions.



It shows as active.



I had to make a rule for the Roku, but everything else should be going through the tunnel...I think.



So, it appears to me that this should work, but, again it seems obvious.

 

[Sky-Knight]

Those static DNS entries don't do what you think they do. You just told Untangle to push any look ups for a domain name of pia to those IP addresses... which while valid is useless.

Edit your LAN interface, or whatever interface is passing out DHCP for the devices you want to use the VPN DNS, and on the DHCP Configuration tab, you need to put a comma separated list of IP addresses in the DNS Override box. No spaces!

So probably this: 209.222.18.222,209.222.18.218

Then once saved, you'll need to force all your lan devices to renew their DHCP lease and they'll get the above addresses for DNS use instead, and assuming the tunnel is online Untangle has normal ISP DNS, the stations use the VPN provider.

Warning, this means your Untangle is no longer doing DNS for those clients, which means anything you put into the DNS tab won't work.

An alternate solution, if you want to leave your LAN alone and have an easy way to turn the DNS forwarding on and off, is to use a port forward rule.

Destined Local
Source Interface: Internal
Protocol: TCP & UDP
Destination port: 53

New destination: 209.222.18.222
New port: <blank>

That rule will redirect any DNS traffic destined for Untangle itself, sourced from the network attached to the Internal interface, to the first of the two listed DNS servers provided by the VPN provider. This rule will not impact Untangle itself, and therefore requires no further configuration changes. If your tunnel goes down, DNS resolution will be lost for any devices on the LAN in question until you disable the rule.

Again, you're bypassing Untangle's DNS services to make this work, so everything on the DNS tab becomes irrelevant. To your devices on the LAN.

 

[Mike McCall]

Ok, thanks. I used the port forwarding option and it seems to be working. I had looked in te Untangle support area and came up empty. Just recently saw your posts there.

It seems to me this could be handled better in Untangle as it doesn't seem very intuitive. Perhaps it's just me.

 

[Sky-Knight]

It's not intuitive, but it's also not easy.

I'm honestly not sure how to handle this. The stations will use whatever DNS they're configured to use, which by default is Untangle. Now Untangle uses all the DNS addresses listed on any marked WAN interface, in a round robin. This behavior is identical to most resolvers.

Now DNSMasq (DNS and DHCP service on Untangle), will resolve the address using whatever it has, and then pass it back to the client.

Now, with TunnelVPN you're asking Untangle to resolve DNS queries it's receiving, from specific devices, using specific servers. DNSMasq just flat doesn't have that ability, heck I don't know of a single DNS server that does.

So you then have to configure the DNS resolvers on the clients to use the specific DNS addresses via DHCP, OR use a forward rule to push the traffic to a specific location. This solves the "leak", but it also disables Untangle's own DNS functionality that many networks, my home included, depend on. And if the tunnel goes down, all those systems either configured to use the tunnel DNS via DHCP, or forced there via the port forward won't work because no DNS resolution.

Untangle is all about things working, everything above is full of stuff not working. The reality here is this use case demands different DNS resolution stacks based on which portion of your network is resolving, and when. And honestly, there is no clean way to automate all of that because the network admin has to determine all that.

And for what? There is no "security" added by using a VPN provider. The only thing you functionally get is the ability to access geo locked content. The VPN providers can claim they don't respond to government queries, but they are required to by law. And if they aren't required by law that means you're dealing with a nation that doesn't have the legal foundation to be trusted to begin with. The rest of our security is already handled by basically everything being SSL'd these days.

All of this is bonkers to me, but that's also why the product works as it does. And as you can tell I've spent considerable time thinking about this, and yet I don't have any good solutions. The port forward is the cleanest, and perhaps that could be an option added to the capture rules. But to really be a solution it needs to be able to gracefully fail back to using the ISP DNS or whatever is on external when the tunnel is down.

 

[Mike McCall]

So, unless I'm in China or North Korea there's little to no value in using a VPN? I get that the traffic is only encrypted as far as the VPN exit. From there, everything except my actual ip is visible again. I don't have stock in Reynolds Wrap or anything, but I prefer to be as private as reasonably possible (I know there's no such thing as true privacy). I considered a VPN as a layer in that pursuit. Perhaps it's not worth the bandwidth loss?

 

[Sky-Knight]

Correct, it doesn't do what people think it does. All the VPN does is make all your internet bound traffic leave your ISP's logs, and enter your VPN provider's logs. Your ISP will show most things going to the VPN provider. Now, that MIGHT be an upgrade, depends on the policies of the ISP.

But as far as securing the communications themselves? No, everything is encrypted already, there's almost no unencrypted stuff in use anywhere anymore.

So you're losing bandwidth, to make yourself appear to hit the world somewhere else. Like I said it can be used to bypass geo-ip blocks on content, and it's valuable if you're a globe trotter. But if you're parked up there happily in Oregon all the time, what you're really saying is I want to pay more because I think my ISP might hand some logs to the government. And again the ISP knows which VPN provider you used, so the government will just go there and get the logs there. You aren't evading law enforcement using a reputable VPN provider, and an unreputable one causes more problems that it solves.

And I'm not saying that doesn't have value, it just doesn't provide the "security" advertised.

P.S. You have Untangle right? So if you do globe trot... why not just OpenVPN to home and surf over that? It will be slower... but it still solves the risk of snooping by the local untrusted network. But, if you need speed I've heard of cases where the VPN provider has better peering than the local ISP, so using it might actually be quicker in some areas. It all "depends".

 

[Mike McCall]

Not so much globe trot, but I am onsite or away on occasion. I generally use PIA when I'm out, but I know of no reason not to use OpenVPN.

 

[Sky-Knight]

Other than the OpenVPN client for Android / iOS is a buggy mess that doesn't do what it's told... and the VPN services have that issue largely fixed it for you. Some of them can even use multiple VPN protocols to get around various ISP blocks.

OpenVPN in particular seems to be commonly messed with in conference centers.