Unbound is probably only setting the source IP on the outbound packet, but your default route is still out the WAN interface. That’s why the extra scripts exist to mark DNS packets with fwmark values that are also interpreted by ip rules based on the same fwmark to route out the VPN.
You can run tcpdump on your WAN anytime before you try that script. It will tell you which interface unbound traffic is going though now. I simply use “tcpdump -i ppp0 -p port 53” for PPPoE.I'm certainly going to try the swinson/martineau script and see what my results look like there... I'm very interested in seeing it in action!
@Viktor Jaep
tcpdump -i tun14 -nn -l udp | grep -E '.53([[:space:]]|$)'tcpdump -i tun14 -nn -l udp | grep -E '(((25[0-5]|(2[0-4]|1[0-9]|[1-9]|)[0-9])\.){3}(25[0-5]|(2[0-4]|1[0-9]|[1-9]|)[0-9]))\.53([[:space:]]|$)'
Your gifts are both a blessing, and a curse sometimes hahahaha. However, thank you for being around to point out the missed obvious observations.
Nope... this one captured the last 53 in the timestamps:
I changed this one to use tun14... and... nope. No output. Leaving it eth0, I'm seeing lots of port 53's. And the other interesting thing here is that they all show as inbound return results all coming back to my WAN IP. There's nothing showing going outbound from VPN or WAN on 53.
What about
tcpdump -i br0 -nn -l udp | grep -E '(((25[0-5]|(2[0-4]|1[0-9]|[1-9]|)[0-9])\.){3}(25[0-5]|(2[0-4]|1[0-9]|[1-9]|)[0-9]))\.53([[:space:]]|$)'
There’s not much mystery here.
tcpdump -i eth0 -n udp and dst port 53So the real question is, If he is under the impression unbound is travelling via VPN, why is he having a return on WAN? or would he see the VPN tunnel talk back to WAN and then WAN talk back to Unbound?
Yeah, this one shows some interesting results that need further analysis... some port 53 lookups go out over VPN and back, but it seems it's only google, and it does it every 2 seconds.
Changing this to tun14, it doesn't show any traffic...
admin@RT-AC86U-DBA8:/tmp/home/root# tcpdump -i wg12 -p port 53 | grep dell
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg12, link-type RAW (Raw IP), snapshot length 262144 bytes
09:52:22.085078 IP 10.5.0.2.4971 > a.gtld-servers.net.domain: 36149% [1au] A? dell.com. (37)
09:52:22.085172 IP 10.5.0.2.36781 > f.gtld-servers.net.domain: 62392% [1au] A? dell.com. (37)
09:52:22.269325 IP 10.5.0.2.19437 > a9-65.akam.net.domain: 881% [1au] A? www.dell.com. (41)
09:52:22.323743 IP a9-65.akam.net.domain > 10.5.0.2.19437: 881*- 1/0/1 CNAME www1.dell-cidr.akadns.net. (80)admin@RT-AC86U-DBA8:/tmp/home/root# /jffs/addons/wireguard/Scripts/custom/unbound_DNS_via_wgc.sh 2 stop
Unbound_DNS_via_wgc: Unbound DNS resolution routed through WAN
admin@RT-AC86U-DBA8:/tmp/home/root#
admin@RT-AC86U-DBA8:/tmp/home/root#
admin@RT-AC86U-DBA8:/tmp/home/root# tcpdump -i ppp0 -p port 53 | grep hp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
09:53:23.970892 IP X.X.X.X.9471 > e.gtld-servers.net.domain: 4087% [1au] A? hp.com. (35)
09:53:23.971307 IP X.X.X.X.31005 > a.gtld-servers.net.domain: 57509% [1au] A? hp.com. (35)
09:53:23.971720 IP X.X.X.X.53630 > c.gtld-servers.net.domain: 40731% [1au] A? hp.com. (35)
09:53:23.972464 IP X.X.X.X.37829 > d.gtld-servers.net.domain: 10076% [1au] A? hp.com. (35)
09:53:24.127789 IP X.X.X.X.5383 > ns5.hp.com.domain: 50939% [1au] A? www.hp.com. (39)
09:53:24.128090 IP X.X.X.X.27520 > ns2.hp.com.domain: 43699% [1au] A? www.hp.com. (39)
09:53:24.129950 IP X.X.X.X.51549 > ns4.hp.com.domain: 40122% [1au] A? www.hp.com. (39)
09:53:24.130028 IP X.X.X.X.56969 > ns1.hp.com.domain: 55664% [1au] A? www.hp.com. (39)
09:53:24.140048 IP ns5.hp.com.domain > X.X.X.X.5383: 50939*- 1/0/1 CNAME www.hp.com.edgekey.net. (75)
09:53:24.140390 IP X.X.X.X.25615 > a16-65.akam.net.domain: 37545% [1au] A? hp.com.edgekey.net. (47)
09:53:24.325285 IP ns4.hp.com.domain > X.X.X.X.51549: 40122*- 1/0/1 CNAME www.hp.com.edgekey.net. (75)
...hahaha probably one of your scripts looking up google.
It means DNS traffic is not going through tun14.Changing this to tun14, it doesn't show any traffic...
I concur, if things are working as they should with @Viktor Jaep setup, the one @dave14305 proposes makes sense.
The source IP (VPN IP) is probably being masqueraded out the WAN interface. Without the routing rules, this is what you get.
It completely makes sense then. I think the only accurate way to view it is from the connection tracking page.
That page is runnng
netstat-nat -r state -xn which supports the theory that the VPN IP is just getting natted/masqueraded.
No point since the traffic doesn’t get routed out the tun14 interface. And you wouldn’t want to masquerade it with the tun14 internal IP anyway.
No permit required. Just maintaining the expectations around here- Half-witted responses with no real results.Do you have a permit to keep shooting in the dark?
www.snbforums.com
