Connection is not secure

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Author Message
neilish2000
DD-WRT Novice


Joined: 14 Apr 2019
Posts: 4

PostPosted: Wed May 08, 2019 0:07    Post subject: Connection is not secure Reply with quote
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.
Sponsor
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Wed May 08, 2019 2:36    Post subject: Reply with quote
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).

Code:
tun11      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:10.13.0.30  P-t-P:10.13.0.29  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
           RX packets:31889 errors:0 dropped:0 overruns:0 frame:0
           TX packets:24667 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:22252393 (21.2 MiB)  TX bytes:4588853 (4.3 MiB)


So the IP assigned to the OpenVPN client is 10.13.0.30.

So now let's dump connection tracking using the following command (as written, it continually updates the dump every 5 secs).

Code:
while :; do clear; cat /proc/net/ip_conntrack | grep ' dport=53 ' | sort -k4; sleep 5; done


And here is a snapshot of one of those dumps.

Code:
udp      17 23 src=10.13.0.30 dst=1.0.0.1 sport=18061 dport=53 src=1.0.0.1 dst=10.13.0.30 sport=53 dport=18061 mark=0 use=2
udp      17 23 src=10.13.0.30 dst=1.0.0.1 sport=18304 dport=53 src=1.0.0.1 dst=10.13.0.30 sport=53 dport=18304 mark=0 use=2
udp      17 18 src=10.13.0.30 dst=1.0.0.1 sport=22112 dport=53 src=1.0.0.1 dst=10.13.0.30 sport=53 dport=22112 mark=0 use=2
udp      17 23 src=10.13.0.30 dst=1.0.0.1 sport=24214 dport=53 src=1.0.0.1 dst=10.13.0.30 sport=53 dport=24214 mark=0 use=2
udp      17 23 src=10.13.0.30 dst=1.0.0.1 sport=26272 dport=53 src=1.0.0.1 dst=10.13.0.30 sport=53 dport=26272 mark=0 use=2
udp      17 24 src=10.13.0.30 dst=1.0.0.1 sport=36902 dport=53 src=1.0.0.1 dst=10.13.0.30 sport=53 dport=36902 mark=0 use=2
udp      17 1 src=10.13.0.30 dst=1.0.0.1 sport=58549 dport=53 src=1.0.0.1 dst=10.13.0.30 sport=53 dport=58549 mark=0 use=2
udp      17 23 src=10.13.0.30 dst=1.0.0.1 sport=7239 dport=53 src=1.0.0.1 dst=10.13.0.30 sport=53 dport=7239 mark=0 use=2
udp      17 18 src=10.13.0.30 dst=1.1.1.1 sport=22112 dport=53 src=1.1.1.1 dst=10.13.0.30 sport=53 dport=22112 mark=0 use=2
udp      17 18 src=10.13.0.30 dst=8.8.4.4 sport=22112 dport=53 src=8.8.4.4 dst=10.13.0.30 sport=53 dport=22112 mark=0 use=2
udp      17 18 src=10.13.0.30 dst=8.8.8.8 sport=22112 dport=53 src=8.8.8.8 dst=10.13.0.30 sport=53 dport=22112 mark=0 use=2
udp      17 23 src=192.168.61.117 dst=192.168.61.1 sport=51123 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=51123 mark=0 use=2
udp      17 24 src=192.168.61.117 dst=192.168.61.1 sport=53348 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=53348 mark=0 use=2
udp      17 23 src=192.168.61.117 dst=192.168.61.1 sport=53713 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=53713 mark=0 use=2
udp      17 20 src=192.168.61.117 dst=192.168.61.1 sport=56256 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=56256 mark=0 use=2
udp      17 23 src=192.168.61.117 dst=192.168.61.1 sport=56562 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=56562 mark=0 use=2
udp      17 23 src=192.168.61.117 dst=192.168.61.1 sport=60157 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=60157 mark=0 use=2
udp      17 23 src=192.168.61.117 dst=192.168.61.1 sport=60976 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=60976 mark=0 use=2
udp      17 21 src=192.168.61.117 dst=192.168.61.1 sport=61191 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=61191 mark=0 use=2
udp      17 24 src=192.168.61.117 dst=192.168.61.1 sport=64817 dport=53 src=192.168.61.1 dst=192.168.61.117 sport=53 dport=64817 mark=0 use=2
udp      17 18 src=192.168.61.118 dst=192.168.61.1 sport=59609 dport=53 src=192.168.61.1 dst=192.168.61.118 sport=53 dport=59609 mark=0 use=2
udp      17 65 src=192.168.61.238 dst=192.168.61.1 sport=46726 dport=53 src=192.168.61.1 dst=192.168.61.238 sport=53 dport=46726 [ASSURED] mark=0 use=2
udp      17 65 src=192.168.61.238 dst=8.8.8.8 sport=46146 dport=53 src=8.8.8.8 dst=10.13.0.30 sport=53 dport=46146 [ASSURED] mark=0 use=2
udp      17 1 src=192.168.61.60 dst=192.168.61.1 sport=51021 dport=53 src=192.168.61.1 dst=192.168.61.60 sport=53 dport=51021 mark=0 use=2
udp      17 29 src=192.168.63.220 dst=8.8.4.4 sport=49116 dport=53 [UNREPLIED] src=8.8.4.4 dst=10.13.0.30 sport=53 dport=49116 mark=0 use=2
udp      17 25 src=192.168.63.220 dst=8.8.8.8 sport=39433 dport=53 src=8.8.8.8 dst=10.13.0.30 sport=53 dport=39433 mark=0 use=2


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.
neilish2000
DD-WRT Novice


Joined: 14 Apr 2019
Posts: 4

PostPosted: Wed May 08, 2019 5:56    Post subject: Reply with quote
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?
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Wed May 08, 2019 6:19    Post subject: Reply with quote
neilish2000 wrote:
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.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Wed May 08, 2019 7:29    Post subject: Reply with quote
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.

Code:
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -I FORWARD -o $WAN_IF -p tcp --dport 53 -j REJECT
iptables -I FORWARD -o $WAN_IF -p udp --dport 53 -j REJECT
iptables -I OUTPUT -o $WAN_IF -p tcp --dport 53 -j REJECT
iptables -I OUTPUT -o $WAN_IF -p udp --dport 53 -j REJECT


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.

Code:
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -D FORWARD -o $WAN_IF -p tcp --dport 53 -j REJECT
iptables -D FORWARD -o $WAN_IF -p udp --dport 53 -j REJECT
iptables -D OUTPUT -o $WAN_IF -p tcp --dport 53 -j REJECT
iptables -D OUTPUT -o $WAN_IF -p udp --dport 53 -j REJECT


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.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum