Some FF Extensions Leading to DnsLeak When Using a Proxy Despite of WebRTC Blocking

My current configuration is the following: I use a vpn, and have un proxy (socks or http) activated on my everyday browser (FF)

I had a long time ago protected my browser (FF) against "dns leak" (webrtc bloking), and have make that the dns will be performed by my proxy dns resolver in setting network(.)proxy(.)socks_remote_dns to true.

But some weeks ago, a DnsLeak test revealed not only my proxy Dns resolver IP, but my vpn dns resolver IP, too.

So, using my proxy was no more hiding that I used a vpn behind it. Moreover, both my vpn provider identity and the vpn server in use could be deduced from that data. Bad.

I had a really hard time to find what was wrong: My browser has a lot of addons installed, and moreover the culprits where 2 different addons, each of them leading to the previous dns leak. To make things worse, concerning one of these addons, the culprit was only one of this many options.

These two addons are Port Authority and... uBlock0, and more precisely the option "uncloack canonical name" I have checked months ago.

The dns leak is due to the way FF handles CName.

I could have of course deactivated Port Authority and the CName uncloaking in uBlock, but I wanted the features offered by these addons.


A workaround has been to use the in-browser DoH feature, with the preference network(.)trr(.)mode = 3. Also in that case I had to replace (in my proxy manager) any Proxy url by the corresponding Proxy IP in order a dns resolution could happen.

After testing my configuration, many time on different Dns Leak test site, I saw the problem was solved, in the sense that my vpn dns ip no more appeared in the tests.

Not sure if it applies in this context as I'm not familiar with those addons, but there's an easy solution to DNS leaks that I never see mentioned: remove all name servers from the adapter that is prone to leaking. That is, your "real" connection when using a VPN, and both of them on a setup like yours. Same thing for IPv6 leaks, just turn off that protocol. Easy to implement as a post-connect script and very effective.

I did the same thing with the default gateway before OpenVPN switched to adding two /1 routes on the virtual adapter instead of the usual /0.

Quote:

---

Originally Posted by anon

Not sure if it applies in this context as I'm not familiar with those addons, but there's an easy solution to DNS leaks that I never see mentioned: remove all name servers from the adapter that is prone to leaking. That is, your "real" connection when using a VPN, and both of them on a setup like yours. Same thing for IPv6 leaks, just turn off that protocol. Easy to implement as a post-connect script and very effective.

I did the same thing with the default gateway before OpenVPN switched to adding two /1 routes on the virtual adapter instead of the usual /0.

---

I'm not sure to completely understand what you mean by "remove all name servers from the adapter that is prone to leaking". In my case, in order to prevent my vpn connection leak my ISP Dns IP, the fields "use the followed Dns IP" in my Ethernet or WiFi adapter are filled by 0.0.0.0 for IPv4, and :: for IPv6. Is it that kind of removing you was speaking about? In any case it works: I have never detected any dns leakage from my ISP despite many tests.

Under Windows, DNS IPs are not mandatory for an adapter and you can leave them completely empty, even if DHCP is enabled. Setting them to all zeros is essentially the same. For Linux, however, that may not work as 0.0.0.0 maps to localhost when used as a destination address... also, its handling of DNS is far more complex than you'd imagine.

https://zwischenzugs.com/2018/06/08/...lookup-part-i/

Semi-quasi-potentially related, since it has an option to prevent leaks. I recently discovered YogaDNS exists. I'm happy with Acrylic (and it's free software), but this one is from the company as Proxifier and just as powerful.

Also, if you set a "Socks" type proxy under Internet Settings, be aware that equates to SOCKS4, and therefore anything that uses the WinInet API will go through that proxy but do DNS lookups locally. Microsoft never added support for 4a and 5 simply because no one ever asked.