Yes , it's working
I have already mentioned
Glad you got it working.
If your problem is solved, feel free to mark the relevant post as the solution; and edit the title to add "[SOLVED]" to the beginning (click the pencil behind the topic).
I still don't understand what the problem was here.
By using OpenDNS, doesn't mean that you bypass the vpn, you are reaching OpenDNS through the tunnel.
If by removing the OpenDNS doesn't work, it might mean that 10.64.0.1 is not a valid DNS. You can check that by running the command nslookup www.google.com 10.64.0.1 in order to force the name resolution from that particular nameserver.
1 Like
I wanted to know why dns traffic does not go through the tunnel
first two screenshot have dns leaks (I forgot to mention it)Wireguard and dns leaks
and I did not understand why traffic dns does not go through the vpn tunnel
I managed to run this dnsleaks test. It basically tells you which nameserver you are using, so I don't understand why did you erase the results, but anyway.
You cannot expect to see there the 10.64.0.1 (if that is actually a nameserver), because the address is private.
2 Likes
I don't want to see there 10.64.0.1 .
I want to see any ip address which provides mullvad vpn.
I hid my ISP data there (first two screenshot )
I remind, without whis changes
i have DNS leaks
Perhaps the route to your ISP DNS-server is shorter, that's why.
Disable peer-DNS.
In the first screenshot you got some replies from your provider DNS, because you were still using it, one way or the other, most likely the tunnel was down during the beginning of the test, so everything was routed through your ISP. If you don't want that, you should not accept the Nameservers advertised by your ISP and use only the NS from your vpn. This means that you will not have name resolution until the vpn tunnel is up and you can only connect to the vpn by IP (unless you make a binding of vpn endpoint name to IP in /etc/hosts)
2 Likes
It happens not only at the beginning, but and after ~30minutes
can i still check it with tcpdump?
That would be overkill. Leave a ping/mtr running to the gateway and check periodically for dropped packets.
2 Likes
If you meant to check the nameserver that is used, run:
tcpdump -i WGINTERFACE -vvvn port 53
1 Like
result with mtr from notebook
My traceroute [v0.85]
pc (0.0.0.0) Wed Jan 16 20:11:22 2019
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.99.1 0.0% 24 3.5 3.3 1.5 4.0 0.4
2. 10.64.0.1 50.0% 23 45.7 48.1 45.7 55.5 2.5
3. vlan704.as01.fra4.de.m247.com 0.0% 23 47.3 47.5 45.8 50.8 0.8
4. vlan599.agg1.fra4.de.m247.com 0.0% 23 46.7 47.5 45.9 50.3 0.9
5. 212.103.51.49 0.0% 23 53.3 48.1 46.5 53.3 1.4
6. 37.120.128.253 0.0% 23 48.1 47.9 46.4 50.6 0.9
7. de-cix1.RT.ACT.FKT.DE.retn.net 0.0% 23 79.1 78.2 74.8 86.4 3.1
8. GW-Akamai.retn.net 0.0% 23 47.6 48.1 45.9 50.3 1.0
9. a72-246-101-185.deploy.static.ak 0.0% 23 47.1 48.1 46.6 49.7 0.4
At this time, I started the extended test on the site dnsleaktest.com from the tablet (saw again dns from ISP)
Interfaces - WAN ,uncheck Use DNS servers advertised by peer
Use custom DNS servers
I did not touch these settings. that clean , specially for the test.
i forgot that in the wifi settings on the laptop was set up google DNS ( when make this test.
Okay I think I know what is going on here...
8.8.8.8 and 8.8.4.4 are Google DNS. Device 10.99.197.255 is using them to resolve names to addresses, along with 10.64.0.1, which is nameserver from the vpn provider. Traffic towards these NS goes through the tunnel. I'll take a wild guess here and say it is Android, so they are hardcoded.
I suppose it was these 2 IP addresses you erased from the screenshots? If you had left them we would have found out earlier what was the problem.
Add the following in the firewall script and you'll be fine.
iptables -t nat -N dnshijack
iptables -t nat -A dnshijack -p udp --dport 53 -j REDIRECT
iptables -t nat -A dnshijack -p tcp --dport 53 -j REDIRECT
iptables -t nat -I prerouting_lan_rule -p tcp --dport 53 -d 192.168.99.1 -j ACCEPT
iptables -t nat -I prerouting_lan_rule -p udp --dport 53 -d 192.168.99.1 -j ACCEPT
iptables -t nat -I prerouting_lan_rule -p tcp --dport 53 -d 10.64.0.1 -j ACCEPT
iptables -t nat -I prerouting_lan_rule -p udp --dport 53 -d 10.64.0.1 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
You are creating a hijack chain in the nat trable and whatever goes there is redirected to the router to port 53. If port 53 packets don't go to Openwrt or VPN for resolving, they are sent to hijack chain.
2 Likes
i forgot that in the wifi settings on the laptop was set up google DNS ( when make this test.
make again?
Yes, go ahead.
half from tablet, half from laptop
https://ptpb.pw/bkwp
I don't see ISP DNS in the log, but i see on tablet and laptop
still added
https://ptpb.pw/kC6h
update
https://dnsleak.io on the site have same test
forgot to mention, device on iOS(iphone) which connected to the same wifi network don't have this leak
I mentioned in my previous post that Google Nameservers are most of the times hardcoded in android devices to provide connectivity checking, name resolution, and tracking 
Apply the firewall rules and the all requests will be forwarded to your Openwrt.
1 Like