Jump to content
Not connected, Your IP: 3.134.78.106

Recommended Posts

Hello.

First you should SEARCH THE FORUM!

Then you should do what THEY TELL YOU ON THE SITE!

Then you may ask a stupid question.

Besides, I doubt that leaking the IP of your DNS of your ISP will greatly impact your anonymity, especially if you are with a big ISP.

For me using a fixed DNS fixes the "problem".

Share this post


Link to post

Testing with http://www.dnsleaktest.com/ shows my ISP IP address.

IS this a problem, if so how can I fix it.

Running windows vista.

Thanks

Hello!

We recommend to use Comodo Firewall in order to fix not only the Windows-endemic DNS leaks, but also to prevent ANY leak.

Please see the permanent links in Announcements section of the forum (displayed every time you select "Support"->"Forum") to see how to prevent leaks with Comodo, pf and iptables.

Direct link for Windows+Comodo:

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142

DNS leaks (and above all leaks due to unexpected VPN disconnection) may be worrying for people who live in human-rights hostile countries or in countries where p2p swarm monitoring is legal, so we recommend to spend a few minutes to install and configure a good firewall, it's really worth the (little) effort.

Kind regards

Share this post


Link to post

Hello admin,

I am using the Global Rules Method with Comodo

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142

and everything works fine.

In particular, as per the Rules, outbound UDP connections through my physical adapter are of course blocked on port 53 (as on any other ports).

And yet, when testing with www.dnsleaktest.com

I get a couple of InternetService Provider addresses, some of which are in other countries, but one among them is in my home country (and incidentally, this is my provider)

Now I am wondering: Is this a coincidence? Should the Global Rules Method not block all DNS leaks because none are allowed if they don't pass through the VPN?

So it might indeed be coincidence that DNS queries through AirVPN use DNS servers, one of whom happens to be in my actual country and happens to be run by my actual ISP.

I just would like to get confirmation that this may be a coincidence!

Share this post


Link to post

Hello admin,

I am using the Global Rules Method with Comodo

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142

and everything works fine.

In particular, as per the Rules, outbound UDP connections through my physical adapter are of course blocked on port 53 (as on any other ports).

And yet, when testing with www.dnsleaktest.com

I get a couple of InternetService Provider addresses, some of which are in other countries, but one among them is in my home country (and incidentally, this is my provider)

Now I am wondering: Is this a coincidence? Should the Global Rules Method not block all DNS leaks because none are allowed if they don't pass through the VPN?

Hello!

The Global Rules showed in the provided link block DNS leaks. If your ISP DNS IP addresses appear in the leak test, either there's actually a leak (therefore some mistake in the rules or network zones), or your provider has public DNS and your device is forced to use them. In this case, the DNS queries are tunneled and your provider will see the queries coming from our VPN server, so the leak is not real.

Please feel frees to end us your Global Rules and the definition of you Network Zones for a check.

Kind regards

Share this post


Link to post

Thanks a lot for the fast reply!

I have sent you the requested Comodo configurations as .jpg screenshots privately to info@airvpn.org

One thing I forgot to mention is that I do NOT use the Comodo secure DNS servers (I unselected this option during the installation of Comodo), and I also unselected Defense+ (but this has nothing to do with DNS, I suppose).

So my Internet Protocol (TCP/IP) Properties in Windows for my physical adapter and for the virtual VPN adapter are both set to "obtain DNS server addresses automatically".

Share this post


Link to post

Thanks a lot for the fast reply!

I have sent you the requested Comodo configurations as .jpg screenshots privately to info@airvpn.org

One thing I forgot to mention is that I do NOT use the Comodo secure DNS servers (I unselected this option during the installation of Comodo), and I also unselected Defense+ (but this has nothing to do with DNS, I suppose).

So my Internet Protocol (TCP/IP) Properties in Windows for my physical adapter and for the virtual VPN adapter are both set to "obtain DNS server addresses automatically".

Hello!

Mail received and we confirm that Comodo configuration is all right. The Google DNS you see in the test are fine. You should never see your ISP DNS IP addresses. Should you see them again, further tests will be necessary.

Kind regards

Share this post


Link to post

Dear admin,

But I *do* regularly see my ISPs DNS servers when performing the DNS Leak test. Please refer to my private message to you (to info@airvpn.org). In my private message, I have copied you an example output of the DNS-leak test results, which shows my private ISP in addition to the Google DNS servers.

Share this post


Link to post

Dear admin,

But I *do* regularly see my ISPs DNS servers when performing the DNS Leak test. Please refer to my private message to you (to info@airvpn.org). In my private message, I have copied you an example output of the DNS-leak test results, which shows my private ISP in addition to the Google DNS servers.

Hello!

Either you have a DNS leak (which is a privacy risk) or you're tunneling DNS queries to your ISP DNS (which is not worrying). About the first case, your computer can communicate to your router, so please check whether DNS queries are sent to your router IP address. Chances are that your router then queries your ISP DNS servers (obviously out of the tunnel), causing the leak.

If it's the case, just replace your rule pertaining to your Home network in order to block packets toward port 53 UDP with 2 or 3 different rules:

For example:

Allow TCP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where Source Port Is Any And Destination Port Is Any

Allow UDP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where Source Port Is Any And Destination Port Is Not 53

OPTIONAL, only if you need it:

Allow ICMP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where ICMP Message Is Any

Kind regards

Share this post


Link to post

Hi admin, thanks for the great advice! I tried our the modified Home Network rules you suggest, and voilà, the DNS leak was gone!

Looking into the Firewall Events log in Comodo, it turns out, that indeed, my PC had sent DNS queries to the router, which then passed them on to my real provider's DNS servers.

Just out of curiosity: Can this kind of leak ONLY happen with DNS queries? I mean, even with the modified Comodo rules you suggested, my PC can still communicate with the router with TCP and UDP (except for port 53), so can any other data leak out through the router this way?

Also, in a private message, I had sent you detailed information about my router and ipconfig settings. If you saw this info, were you able to see what setting (possibly in the router) was the culprit for the DNS leak?

Thanks again, your support is absolutely outstanding!!!

Share this post


Link to post

Hi admin, thanks for the great advice! I tried our the modified Home Network rules you suggest, and voilà, the DNS leak was gone!

Looking into the Firewall Events log in Comodo, it turns out, that indeed, my PC had sent DNS queries to the router, which then passed them on to my real provider's DNS servers.

Hello!

We're very glad to know that the problem is solved.

Just out of curiosity: Can this kind of leak ONLY happen with DNS queries? I mean, even with the modified Comodo rules you suggested, my PC can still communicate with the router with TCP and UDP (except for port 53), so can any other data leak out through the router this way?

No, it's not possible (see below).

Also, in a private message, I had sent you detailed information about my router and ipconfig settings. If you saw this info, were you able to see what setting (possibly in the router) was the culprit for the DNS leak?

The "culprit" is Windows. Windows lacks the concept of global DNS, so each card can have its own DNS server IP addresses. The DNS server IP configured (DHCP pushed) on your physical interface is 192.168.0.1. So in every case of a DNS query which does not "obey" to the routing table, the query is sent to your router (configured to act as a DNS server), and not blocked by Comodo (because we allow communications in the home network, which is vital, otherwise it would not be possible to communicate with the router). Then the router sends the unencrypted query to your ISP DNS. By blocking communications in your home network toward port 53 UDP the problem is solved because DNS queries can go only to that destination port.

Other options to block the leaks are forbidding DHCP DNS push from the router (just configure your WiFi card with any fixed primary and secondary DNS you like, so that any leak will be blocked by Comodo by the already existing rules) or blocking with Comodo UDP packets toward 192.168.0.1 port 53 (remember, in this case, to modify this rule if you change the address of the router).

Thanks again, your support is absolutely outstanding!!!

Thank you!

Kind regards

Share this post


Link to post

Thanks a lot for the detailed explanation!!!

One last question: Instead of the two (or optional three) allow-rules you suggested, would there also be the option to use the following two rules (MUST BE IN THIS ORDER):

Block UDP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is 53

Allow IP In/Out From In [Home Network] To In [Home Network] Where Protocol Is Any

I know that this is a tiny little bit more lenient than the rules you suggested (since this also allows IGMP events for example), but it's more consistent with the instructions laid out in https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142

so I wondered if I could also do it this way.

Would the above two rules also be possible to plug the router DNS leaks? From the leak-test website http://www.dnsleaktest.com, it seems to work fine, no DNS leaks!

Thanks again for the help!

Share this post


Link to post

Thanks a lot for the detailed explanation!!!

One last question: Instead of the two (or optional three) allow-rules you suggested, would there also be the option to use the following two rules (MUST BE IN THIS ORDER):

Block UDP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is 53

Allow IP In/Out From In [Home Network] To In [Home Network] Where Protocol Is Any

Would the above two rules also be possible to plug the router DNS leaks? From the leak-test website http://www.dnsleaktest.com, it seems to work fine, no DNS leaks!

Hello!

Yes, in that order they are just fine!

Kind regards

Share this post


Link to post

I have bad news: I tried again with admin's suggested three allow rules (and also with my two rules -- one block port 53 and the original home network all allow rule), and in BOTH configurations, it actually did NOT work anymore, even I thought before that it works.

Whenever I tried to connect to a website I didn't connect to before, it wasn't able to find it.

The reason I thought earlier that it works, is that I always went to the same websites that I had already visited before implementing the Comodo rules (like my homepage, or the DNS-leak test page). Maybe the PC somehow remembered the DNS for these sites.

I don't know what the reason is. But as soon as I use a Comodo rule that does not allow destination port 53 on the home network, it does not work. No idea why.

BUT.... based on what admin wrote before

"Other options to block the leaks are forbidding DHCP DNS push from the router (just configure your WiFi card with any fixed primary and secondary DNS you like, so that any leak will be blocked by Comodo by the already existing rules)"

I tried to just configure my Wifi card with a fantasy primary and secondary DNS server

(I just used 1.1.1.0 and 1.1.1.1), and it WORKS using the ORIGINAL Home Network rule (allow all). I can go to any website, and I DON'T have any DNS leaks. I don't get it....

Question to admin: By writing "any fixed...", did you mean I should use fantasy values, or did you mean I should known trusted DNS server IPs? For some reason, the fantasy values I used seem to work. But I'm worried that actually these IPs *do* exist somewhere. What would happen if I use IP addresses that do exist, and then send my DNS traffic there? Would that be harmful for my security?

And, I really don't understand why does it works when I use the fantasy values? I mean, I just typed 1.1.1.0 and 1.1.1.1 for the primary and secondary DNS servers in my WLAN adapter settings, and in Comodo I just use the original rule

Allow IP In/Out From In [Home Network] To In [Home Network] Where Protocol Is Any

.... and it works! But why??

Share this post


Link to post

I tried to just configure my Wifi card with a fantasy primary and secondary DNS server

(I just used 1.1.1.0 and 1.1.1.1), and it WORKS using the ORIGINAL Home Network rule (allow all). I can go to any website, and I DON'T have any DNS leaks. I don't get it....

Question to admin: By writing "any fixed...", did you mean I should use fantasy values, or did you mean I should known trusted DNS server IPs? For some reason, the fantasy values I used seem to work. But I'm worried that actually these IPs *do* exist somewhere. What would happen if I use IP addresses that do exist, and then send my DNS traffic there? Would that be harmful for my security?

Hello!

It makes no difference: all the DNS queries outside the tunnel are blocked by the Comodo block rule, so there can't be and leak.

And, I really don't understand why does it works when I use the fantasy values? I mean, I just typed 1.1.1.0 and 1.1.1.1 for the primary and secondary DNS servers in my WLAN adapter settings, and in Comodo I just use the original rule

Allow IP In/Out From In [Home Network] To In [Home Network] Where Protocol Is Any

.... and it works! But why??

Because the DNS queries are sent only inside the tunnel toward the TAP-Win32 DNS IP address. DNS queries outside the tunnel are blocked by:

Block And Log IP In/Out From MAC Any To MAC Any Where Protocol Is Any

Kind regards

Share this post


Link to post

Thank you, admin, for the explanation. I am glad I found a way what works for me.

What I still don't understand is, how does Windows now decide which DNS server address to use for the query?

Since I configured my physical adapter with two fixed (dummy) DNS addresses, the query will not go to the router. Instead, it will try to go to these dummy addresses directly, and this will be blocked by the block-all rule in Comodo. What happens to the query then? After all, it must go out (and somehow it does go out, since now it works for me!).

Does Windows then (by default) send the query to the internet, and therefore through the tunnel?

But to what DNS server address? How will receive the query (first)?

Share this post


Link to post

Thank you, admin, for the explanation. I am glad I found a way what works for me.

What I still don't understand is, how does Windows now decide which DNS server address to use for the query?

Hello!

The trigger of the leak can be a matter of discussion for the Microsoft customers' support. Apparently, any delay in a DNS query response inside the tunnel (or in general from a network interface) may trigger another DNS query from another interface. Apparently this is a consequence of a very bad design... but perhaps Microsoft may be able to give some justification for this mess.

Since I configured my physical adapter with two fixed (dummy) DNS addresses, the query will not go to the router. Instead, it will try to go to these dummy addresses directly, and this will be blocked by the block-all rule in Comodo. What happens to the query then? After all, it must go out (and somehow it does go out, since now it works for me!).

Only DNS queries inside the tunnel are allowed (rule "Allow TCP or UDP In/Out From In [AirVPN] To MAC Any... etc.). All the others are dropped by Comodo block rule.

Kind regards

Share this post


Link to post

Does it mean that (by the Windows cryptic default rules), the DNS query would then make its way through the next available network adapter, which is the AirVPN TAP-adapter, and would thus go to 10.4.0.1?

And one last question: I know I could just use *dummy* DNS addresses for the fixed primary and secondary DNS addresses in my physical adapter (for example my WLAN card), since these are blocked by Comodo anyway.....

But, in order for DNS to work on my PC even when AirVPN and even Comodo is *not* run, it might still be good to use reliable working DNS server addresses here. Which ones would you recommend?

For, example I could use the two addresses that Comodo calls "Comodo secure DNS", i.e.

Preferred DNS server: 8.26.56.26

Alternate DNS server: 156.154.70.22

but maybe you would rather recommend others here because of filtering issues, DNS server reliability issues or net neutrality issues?

Share this post


Link to post

Does it mean that (by the Windows cryptic default rules), the DNS query would then make its way through the next available network adapter, which is the AirVPN TAP-adapter, and would thus go to 10.4.0.1?

Hello!

This needs to be clarified by Microsoft.

And one last question: I know I could just use *dummy* DNS addresses for the fixed primary and secondary DNS addresses in my physical adapter (for example my WLAN card), since these are blocked by Comodo anyway.....

But, in order for DNS to work on my PC even when AirVPN and even Comodo is *not* run, it might still be good to use reliable working DNS server addresses here. Which ones would you recommend?

We don't know how Comodo DNS servers work and we are unaware about their privacy policy. Google DNS are excellent for performance and net neutrality, but they pose too many privacy issues.

You might like to check DNS servers maintained by German and Swiss Privacy Foundations:

http://server.privacyfoundation.de/index_en.html

and Telecomix DNS, a quite interesting project:

http://werebuild.telecomix.org/wiki/DNS

Kind regards

Share this post


Link to post

I fixed my active vpn dns leak in Ubuntu by putting the following in the beginning of the .opvn file:

up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
--script-security 2

Share this post


Link to post

Thanks a lot! As you suggested, I am now using the fixed DNS servers from the Swiss Privacy Foundation on my physical network adapter.

Of course, these addresses are blocked as long as AirVPN and Comodo are running (which is intended since the DNS query must then go through the tunnel to the TAP-adapter DNS server 10.4.0.1 and then is routed anonymously to Google DNS), but the good thing is that, whenever AirVPN and Comodo are off (for example for debugging purposes), my DNS still gets resolved, and according to the Swiss Privacy Foundation, they don't censor or log DNS queries, which is good, too.

Now my question: Would it make sense to also configure the TAP-adapter with the fixed DNS servers of the Swiss Privacy Foundation? Or should I leave 10.4.0.1 there? Is it even possible to change the TAP-adapter DNS without screwing up one's privacy?

And a totally unrelated question: I am using an additional Comodo allow-rule as follows:

Allow IP In/Out From IP 0.0.0.0 To In [Host Group Addresses] Where Protocol Is Any

Here, "Host Group Addresses" are [224.0.0.0 to 239.255.255.255]. The reason for the

rule is that whenever my PC cannot connect to any TCP/IP network, it takes the

dummy IP 0.0.0.0, and sometimes then attempts with this "IP" to connect to an IP

in the host group address range (which in any case is not part of the outside internet).

Since these attempts get blocked by the Comodo "block-all-rule" and clog the log,

I thought I might just as well allow them since they are harmless.

Is is ok to allow them, or is this a security risk?

Share this post


Link to post

I am still wondering if it would be *possible* to configure the AirVPN TAP-adapter with a fixed preferred and alternate DNS server, instead of using the default 10.4.0.1 (that you get in Windows when "obtaining DNS servers automatically").

Would this produce an increased security risk OTHER than the inherent risk arising from the privacy policies of the DNA server company chosen?

(The reason I ask is that I would like to try out the SwissPrivacyFoundation DNS servers for a while and see if there is any difference to the default Google servers that AirVPN uses).

Thanks a lot for any info on this.

Share this post


Link to post

I am still wondering if it would be *possible* to configure the AirVPN TAP-adapter with a fixed preferred and alternate DNS server, instead of using the default 10.4.0.1 (that you get in Windows when "obtaining DNS servers automatically").

Would this produce an increased security risk OTHER than the inherent risk arising from the privacy policies of the DNA server company chosen?

(The reason I ask is that I would like to try out the SwissPrivacyFoundation DNS servers for a while and see if there is any difference to the default Google servers that AirVPN uses).

Thanks a lot for any info on this.

Hello!

You can do that, there are no privacy risks.

Kind regards

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...