Suggestion: User-configurable permanent DNS leak prevention, server side

[zhang888 1066]

Hello!

 

The idea of bringing this up is a result of many questions lately, that some devices or clients override OS settings and query their own DNS servers without the users permission.

 

I would like to suggest a small enhancement, which will potentially prevent all user mistakes in the future, and will allow an even better VPN experience with less configuration.

 

 

The idea is to have 2 additional options in the config generator section of the Client Area, where the user would be able to "opt-in" in case he wants the feature.

One is something like "Force all applications use Air's VPN server", in which case you will have to add something like this:

 

iptables -t nat -A PREROUTING -s 10.4.12.34 -p udp --dport 53 -j DNAT --to 10.4.0.1

iptables -t nat -A PREROUTING -s 10.4.12.34 -p tcp --dport 53 -j DNAT --to 10.4.0.1

 

The internal IP of the client is known to you, here is just examples of how I assume it should look on the server side.

 

The second option in the Client Area, can be called something like "Prevent all potential DNS leaks, I will configure Air's DNS manually"

Then, a rule like this can come in place:

 

iptables -A OUTPUT -p udp -s 10.4.12.34 -d 10.0.0.0/8 --dport 53 -j ACCEPT

iptables -A OUTPUT -p tcp -s 10.4.12.34 -d 10.0.0.0/8 --dport 53 -j ACCEPT

iptables -A OUTPUT -p udp -s 10.4.12.34 --dport 53 -j DROP

iptables -A OUTPUT -p tcp -s 10.4.12.34 --dport 53 -j DROP

 

 

All the examples are made up, I am sure that a more elegant way of achieving this can take place, such as a special subnet for all users of each group.

Today these methods are used in corporate VPNs mainly to enforce whitelisting/blacklisting of URLs, but I don't see a reason why we can't do the same here.

 

Please share your comments

 

zhang888

 

[mage1982 15]

Edit: I totally misread your post and posted a reply that had nothing to do with the suggestion.

 

Is this really the problem though? I thought DNS leaks came from queries going out over the "raw" interface (so your ISP can see where you're going), not from queries going from the exit server back to one's ISP.

[zhang888 1066]

Hi mage1982,

 

Your question is good, that's why I will try to explain a little more about the idea.

I will use live example, that I deploy to my users who are behind a pfSense firewall and Air.

 

Since I cannot physically control each and every device and application, I had to come with a way to force all DNS queries,

to whatever destination server, to pass via my DNScrypt server first.

 

So let's see how it is done in practice:

 

 

This is my simple rule, to catch all traffic from the "LAN" interface, which destination is port 53, and push it to my local port 5353 on the firewall, where

a DNScrypt is listening.

 

 

Now, we should make a small test and see how it will work:

 

 

 

Looks good so far. Seems that all the DNS traffic is being "Hijacked" by my firewall, and pushed to the local resolver.

No matter what destination the client actually tried to query. This is like a transparent DNS proxy.

 

Now, for the final test, we will deliberately set Google's 8.8.8.8 resolver on a random client IP in the LAN.

 

 

 

And here once again, the query was successfully intercepted, and forwarded to the local resolver.

It could be any resolver, such as Air's DNS server for example, which is what I suggested to implement in the post above.

 

Regards! 

[mage1982 15]

Thanks zhang888.

 

I'm even more confused now. I thought you were suggesting intercepting DNS queries server side, but the second example is client side.

 

Are you suggesting that Air's client should configure users' firewalls to block DNS leaks? That would be hard to do, since there's no portable way (that I'm aware of) to poke at firewall configurations. Perhaps the OpenVPN project would be the right place to ask for such a feature.

 

But in the first example it seemed like you were talking about blocking queries on Air's servers. That's easier, I just don't see what the problem is that it would solve.

 

I'm clearly missing something here.

[zhang888 1066]

What I meant is that as the result of my suggestion (see  post #1) the behaivior is going to be similar to properly configured DNS leak prevention firewalls.

I am not talking about Air's client, nor about configuring any user firewall.

 

Only a small addition (for users it should look not more than just a checkbox in the client area) that will have the same effect as in  post #2.

 

Regards

[Staff 9972]

 

What I meant is that as the result of my suggestion (see  post #1) the behaivior is going to be similar to properly configured DNS leak prevention firewalls.

I am not talking about Air's client, nor about configuring any user firewall.

 

Only a small addition (for users it should look not more than just a checkbox in the client area) that will have the same effect as in  post #2.

 

Regards

 

 

Hello,

 

a DNS leak is when a DNS query is sent out of the tunnel. It does not even reach our servers. If a DNS query reaches our server, then it has been tunneled, and we want to leave our clients the freedom to use their favorite DNS, in case they do not want to use our VPN DNS. In case they want to force the VPN DNS, the option you suggest looks just like "Force DNS", which is already implemented in Eddie.

 

iptables -t nat -A PREROUTING -s 10.4.12.34 -p udp --dport 53 -j DNAT --to 10.4.0.1

iptables -t nat -A PREROUTING -s 10.4.12.34 -p tcp --dport 53 -j DNAT --to 10.4.0.1

 

The internal IP of the client is known to you, here is just examples of how I assume it should look on the server side.

 

The second option in the Client Area, can be called something like "Prevent all potential DNS leaks, I will configure Air's DNS manually"

Then, a rule like this can come in place:

 

iptables -A OUTPUT -p udp -s 10.4.12.34 -d 10.0.0.0/8 --dport 53 -j ACCEPT

iptables -A OUTPUT -p tcp -s 10.4.12.34 -d 10.0.0.0/8 --dport 53 -j ACCEPT

iptables -A OUTPUT -p udp -s 10.4.12.34 --dport 53 -j DROP

iptables -A OUTPUT -p tcp -s 10.4.12.34 --dport 53 -j DROP

 

 

Some confusion here, you talk about "config generator section of the Client Area" and at the same time propose a "server side" feature.
You propose a "Force all applications use Air's VPN server" but the iptables refers to "--dport 53", another mistake.

In any case, on client side, all we can implement is done in AirVPN Client. Yes, maybe in the future we can enhance the Config Generator to create some scripts to prevent leaks, but we need to write it in every platform, not only Linux/iptables.

On server side:
- There isn't any 'application leak' that we can manage, because if a packet reaches our server, there isn't any leak.
- There isn't any 'DNS leak', because if a DNS query reaches our server, it's already inside the VPN tunnel.

Note: 'DNS Leak' normally means a DNS request sent outside the VPN tunnel. You are a Linux guy, and DNS leaks never happen in Linux.
DNS leak in Windows exists because Windows sometimes sends the DNS query to the DNS server set on the standard interface (lacking also a global DNS) regardless of the VPN tunnel being estabilished or not. If a Windows executes a DNS query outside the tunnel, our server never receives it, so it's impossible to prevent Windows DNS leaks on server side.
 

Kind regards

[Guest]

I saw this thread and I have learned a lot from this. It's awesome to see interaction with staff and customer. Right or wrong it is very educational to have open discussion like this with the staff of this vpn service. I have much respect to the staff of AIRVPN. To the relivance of this thread. I personally like using forums for answers then again I'm an old fart. The new generation today like automation to simplify (or complicate) the already extremely simple, strong, stable service wrapped up in a GUI. Scripts no doubt seems like a good idea if it was based on individual's needs. I concur about not restricting to only one platform for the need of such enhancement. There would be for all platform they currently support. Thought I'd put in my opinion. Thanks Guys. I have learned something from this.