Posted: Wed May 08, 2019 0:07 Post subject: Connection is not secure
Hello All,
I am using Linksys WRT3200ACM router. I have connected PC and Android IP Box to the router. When I check PC connection via doileak.com, PC connection is scrambled and IP address belongs to VPN service, however when I perform the same test on Android IP Box, it shows IP address belongs to Comcast. Any idea what is going on here? How do I make Android IP Box connection secure? Would appreciate help from forum members.
I don't recommend you trust these online DNS leak testing tools when it comes to the router. For one thing, they never fully reveal how they are making this determination. They just tell you they do or don't suspect a DNS leak. Also, by default, every dd-wrt client is configured to use the router's DNS proxy (DNSMasq), from which the DNS proxy then accesses various public DNS servers (typically those provided by your ISP). If it happens the online tool is using something like WebRTC to examine your local network configuration, it will only see the router's DNS proxy.
The *best* way to determine if you have a DNS leak when it comes to router is to monitor connection tracking and see for yourself exactly which network interface the public DNS queries are being routed over.
I'm going to use my own router (w/ tomato), currently connected to a VPN, to demonstrate. But let's first look at my setup.
I've configured DNSMasq w/ the following so that all my ISP's DNS servers are ignored, and the only public DNS servers I ever use (whether the VPN is up or down) are those specified in the server directives.
Code:
no-resolv # ignore nameservers in /etc/resolv.conf
server=1.1.1.1 # cloudflare nameserver
server=1.0.0.1 # cloudflare nameserver (backup)
server=8.8.8.8 # google nameserver
server=8.8.4.4 # google nameserver
I'm not suggesting you have to do the same. I'm merely explaining how I'm presently configured so that what follows makes sense. Also, all the commands I'm using were done from a shell (telnet/ssh), NOT the GUI.
Here's my ifconfig dump as well, showing the OpenVPN client tunnel (tun11, remember I'm using tomato which uses tun11, dd-wrt uses tun1).
What you will typically see is a whole bunch of DNS queries being made from clients on the local network (192.168.61.x in my case) to the router (192.168.61.1), which in turn makes DNS queries to the various public DNS servers I specified in DNSMasq, on behalf of those clients. Notice that each time the public DNS servers are accessed, it's done using the OpenVPN client's network interface (10.13.0.30), the first src field in each record.
That tells me there are NO DNS LEAKS w/ my current configuration! Now if the src field for those public DNS queries contained the public IP on the WAN, then YES, I would have a DNS leak.
So you can forget about using those online tools. They aren't dependable. The only real proof is examining what the system is actually doing via connection tracking.
One last thing to consider.
AFAIC, a DNS leak isn't just about accessing DNS over the VPN. It also means NOT using your ISP's DNS servers. After all, if you end up still using your ISP's DNS servers but access them over the VPN (which isn't always possible; many ISP's only allow private access, over the WAN, to their own DNS servers), your ISP can still spy on you and alter your DNS queries.
Why does this matter? Because we have two developers (BS and Kong) who handle the DNS servers pushed from the OpenVPN provider differently. In the case of BS, he ignores them. So you end up using your ISP's DNS servers, even w/ the VPN active. OTOH, Kong reconfigures DNSMasq w/ the OpenVPN providers DNS server(s) so that you don't use the ISP's DNS servers.
Because of this discrepancy in the builds, that's why I configured DNSMasq as I did above. I don't care whether I'm using a BS or Kong build because I completely ignore any and all DNS servers except those I've listed as server directives. I'm always using publicly available DNS servers, and never the ones provided by either the ISP or the VPN provider (although many times these VPN providers push the same public DNS servers I'm already using anyway).
Unfortunately, dealing w/ DNS leaks is complicated on dd-wrt. And to be fair, it's complicated on almost any platform. Lots of opportunities to mess it up, both by your own actions, and those of the developers.
Thank you for your detail reply and guidance. I will follow your direction. One more question. With DD-WRT, do both wireless and Ethernet get VPN connection or only wireless?
Thank you for your detail reply and guidance. I will follow your direction. One more question. With DD-WRT, do both wireless and Ethernet get VPN connection or only wireless?
By default, *everything* is forced over the VPN; router, all local clients in the primary network (br0), any guests networks, wired and wireless, everything. The only way to prevent it is to use PBR (policy based routing). When using PBR, the router itself is taken off the VPN (which btw can lead to DNS leaks!), and only those client source IPs listed in that field are forced over the VPN. Everything else continues to use the ISP/WAN.
P.S. Another quick and dirty way to detect if you have a DNS leak is to temporarily block all DNS queries over the WAN. Once the VPN is well established (you don't want to block it before the Server IP/Name has been resolved by the OpenVPN client!), go to a shell (telnet/ssh) and execute the following commands.
What this does is prevent all attempts by either the router itself or clients on the LAN to access DNS (port 53) over the WAN. If suddenly your local clients now stop working, it's probably because there's a DNS leak and they're not getting DNS resolution anymore.
If you reverse the process and delete those rules, and things start working again, that's yet another indication it's a DNS leak.
Examining connection tracking will probably provide more answers as to *why* though. Blocking DNS over the WAN also won't tell you if your using your ISP's DNS servers over the VPN.
