What's new

VPN leaaking after firmware update 1-25-22

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

VNBwtf

New Around Here
I communicated with VPN support for hours today. We went through every page of settings. Nothing prevented the leaking. Is this a known issue with 386.4 ? can anyone suggest solutions? I have already renewed the settings on the router which tends to take some time.
 
386.4? So you're using Asuswrt-Merlin? If so, in the future, it's best to use the Asuswrt-Merlin forum for most issues related to that firmware.

What precisely is leaking? Your ISP assigned public IP? Your DNS? Both? And how do you know it's leaking? IOW, how did you come to this determination?
 
Should I repost or can this entry be transferred to the Asus forum?

I am seeing many, at least 6 DNS, all appear to be Google, and from different countries, suspiciously corresponding to countries of VPN servers I used in days prior. I can clear cache on the web browers but I am concerned with blocking this activity completely.

The public IP itself does not appear to be leaking. I am concerned because in the past browser tests at ipleak and dnsleaktest would only return the VPN server, regardless of how often I cleared browser cache.

I began to test because of slowness and webpages that failed to load on one device. I also get Chinese characters on some sites, such as etsy. My general question is how to prevent Google DNS directly in merlin without affecting the accuracy of browser DNS test results.

I did ask the VPN but they had no solution.
 

Attachments

  • google.jpg
    google.jpg
    97.1 KB · Views: 77
Don't worry about the forum placement at the moment. Just use Merlin in the future.

IMO, the problem w/ these online leak testing tools (at least when it comes to DNS) is rarely if ever do they expose their testing techniques, which makes them highly suspect as to their accuracy. Trying to determine the DNS used by the client is NOT easy. I assume they're using some sort of server and client-side Javascript "trickery" to deduce this information. But in the case where the client is behind a router, one which is providing DNSMasq as a local proxy, and contacting the public DNS server on their behalf, I have NO CLUE how that can be done reliably, if at all. Therefore, I *never* use such tools. I find them worthless.

As I've said many times in the forum, the *only* thing that matters is what connection tracking reports as far as port 53 (853 if using DoT) traffic, and which network interfaces that traffic is using. Once you know that information, and it's working as you expect/desire, it doesn't matter a lick what these online tools report.

One thing to keep in mind though. It's entirely possible (perhaps even likely) that when you configure your router's DNS, the *actual* DNS server doing the resolution is different from the configured servers. IOW, if you're configured to use Cloudflare (1.1.1.1 and 1.0.0.1), that will be obvious in connection tracking. But ultimately those may only be proxies which hand off DNS name resolution to secondary servers. THAT may be what's appearing in the reporting of online DNS leaking testing tools.

It's just another reason why determining how DNS is actually being handled is so difficult. We as end-users have limited information. And so do these online tools. In the end, all that matters is that your router's DNS is configured properly and working as expected. Once it leaves the router, it's out of your hands.

From an ssh session, you can dump connection tracking and easily tell what's happening.

Code:
egrep 'dport=(53|853) ' /proc/net/nf_conntrack

It may seem intimidating at first, but you can quickly learn what the various fields mean by doing a little research w/ Google.

Connection tracking is being constantly updated, so it can be useful to monitor it continuously using the watch command.

Code:
watch -n10 "egrep 'dport=(53|853) ' /proc/net/nf_conntrack"

In terms of network interfaces, the trick is to watch the second dst field. That's the destination IP of the expected reply, and will typically correspond to the IP assigned on either the WAN or VPN. That is how you know where those DNS queries are being routed. And therefore whether you do or don't have a DNS leak.
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top