What's new

DNS Leak

  • 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!

adfontes

New Around Here
Hey Guys.

I have a DNS leak and I hope someone can point me into the right direction to fix it.

What works (no DNS leak):
  • DoT + VPN (without policy rules)
  • VPN + Policy Rules
What does not work (DNS leak):
  • DoT + OpenVPN & Policy Rules enabled
The attached pictures show my current settings.

Hardware: RT-AC86U
Installed scripts: Diversion

Thanks :)
 

Attachments

  • DHCP-Settings.png
    DHCP-Settings.png
    359.2 KB · Views: 177
  • DoT-Settins.png
    DoT-Settins.png
    312.5 KB · Views: 167
  • VPN-Settings.png
    VPN-Settings.png
    230.7 KB · Views: 170
As I've mentioned many times before, when using PBR (policy based routing), this takes the router itself OFF the VPN! And as such, any internet-bound processes on the router will use the WAN, NOT the VPN, by default. That's one of the side effects of PBR that's not always appreciated. It can lead to other subtle problems beyond just DNS leaks.
 
P.S. One of the ways to deal w/ the problem is to explicitly bind the relevant destination IP(s) to the VPN. Ideally, you would do that using route directives (which are nothing more than static routes) in the custom config field of the OpenVPN client.

Code:
route 199.199.199.199 255.255.255.255 vpn_gateway

Or just …

Code:
route 199.199.199.199

(since 255.255.255.255 vpn_gateway is the default)

Note, vpn_gateway is an OpenVPN reserved word. It will automatically substitute the correct VPN gateway IP at runtime.

However, due to another quirk in how PBR is implemented, the router strips out these static routes from the main routing table, making them ineffective! As a result, the remaining alternative is (ironically) to use PBR, but specify the destination IP(s) in the rule(s).

Btw, I mentioned the use of route directives (despite NOT working) because a) some users will be tempted to use them as a workaround, and b) it's my *hope* to someday to see this corrected in the router.
 
Last edited:
At least for my purposes everything is fine now! It turned out that one of Cloudflare's DNS servers is in the same location as my ISP.
I noticed this after switching from Cloudflare to Quad9.

@eibgrad

Thanks for your input on this, I'll keep an eye on it. I have already noticed some of these things.

Here are my notes so far:

Accept DNS Configuration
  • Strict: A check for DNS leaks delivers both kind of servers DoT (e.g. WoodyNet) and VPN servers.
  • Disabled: A check for DNS leaks only delivers DoT servers (WoodyNet).
Policy Rules (Strict)
  • All clients are using the WAN interface per default.
  • VPN clients are unable to connect to devices from the ISP Router's network e.g. 10.0.0.1.
    In order to reach these clients an additional rule needs to be defined: Router --> 10.0.10.0/24 --> Empty --> WAN
 

Similar threads

Sign Up For SNBForums Daily Digest

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