And why it's not always obvious if and when you have one. There are so many configuration options, all of which can affect how DNS is handled, to the point it may even differ from client to client. That's why this whole area of DNS leaks is so tricky. Of course, using a DNS filter introduces its own side-effects, such as having no access to the router's DNS server for local name resolution, ad blocking, or caching (whether that matters to anyone is up to them, but it's just something to be aware of). As such, you're not dependent on how the router is or isn't bound to the VPN for the purposes of DNSMasq (the router's DNS server), which would normally be the case. I don't use DNS Filtering myself, but that's another case where you get around this problem because you are redirecting the DNS queries of those clients to a specific public DNS server. However, if the VPN provider push's *public* DNS servers (e.g., 8.8.8.8 and 8.8.4.4), which does happen from time to time, those will be accessed over the WAN *unless* you add those public IPs as destinations in PBR. And the router knows it based on the current state of the routing table. For example, if the VPN provider push's DNS servers in the same *private* IP space of the tunnel (e.g., 10.8.0.100), those devices are only accessible over the VPN. And which is why I suggested that if you want the router to use the VPN, you need to bind its use of destination IPs using PBR.Īll that said, there are times when despite PBR being active, the router will still use the VPN. IMO, a kill switch should be made possible even if NOT using PBR (see below), because requiring PBR forces the router off the VPN, and as a side-effect, all of its internet-bound access is now done over the WAN. That's one of my complaints about users having to use PBR just to gain access to a kill switch. So having the router's LAN ip in PBR accomplishes nothing! Instead, it will be either the public IP of the WAN, or assigned IP of the VPN, depending on which of the two is configured as the default gateway. And when it needs internet access, those packets do NOT typically use the LAN (192.168.1.1) as their source IP. The router is unique in that it is hosting the internet-bound network interfaces (WAN or VPN). This is a common misunderstanding about how PBR actually works. Including the router's LAN network interface, either implicitly (192.168.1.0/24) or explicitly (192.168.1.1), does NOT solve the problem. >With custom ENABLED Īt see that CleanBrowsing DNS is being contacted. >With your current service provider DISABLED So my browser shouldn't be interfering in DNS. Secure DNS may not be available all the timeĪt see that NordVPN DNS is being contacted. >With your current service provider ENABLED I tried several configurations (OpenVPN, NordLynx-WireGuard), each time turning off/on the VPN tunnel, none resulted in my Custom DNS IP's being contacted. << back to the drawing board - (I have noticed that this updated NordVPN Windows client seems to be a bit buggy)ĮDIT: After trying this myself (the solution was "obvious" FLW) the Custom DNS servers were never contacted. Test DNS configuration at m or to see if your Custom DNS server is actually being used.ĮDIT: After trying this myself (the solution was "obvious" FLW) the Custom DNS servers were never contacted. Toggle the switch to "On" (You may need to turn VPN tunnel off/on) Keep Left Clicking on " Set a DNS server address" to enter up to 4 custom DNS server IP's At the top where it says Left Click on the line " Set a DNS server address" Then enter your Custom DNS server IP. Left Click on the "Cog" at the upper right of the App
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |