agreed. the vpn header info makes it clear.
Tutorial How to monitor DNS traffic in real-time
- Thread starter eibgrad
- Start date
Chuckles67
Regular Contributor
This script is very helpful. Wondering if a Asuswrt-Merlin AddOn version of this script with a web UI tab might be possible some time in the future?
ColinTaylor
Part of the Furniture
DNSFilter
Hi eibgrad I am having another go with this script after having disabled IPv6, but am still a little confused at what I am looking at. I have set Connect to DNS Server automatically to No, removed the non-DoT DNS servers and use 1.1.1.1 and 1.0.0.1 for DoT and am routing upbound through VPN. I haver also rebooted a few times to check that this setup does not cause any issues with my setup (it does not, or at least none that I have spotted)
While I can see that the VPN is showing as the sender for unbound, the recipient is still showing as the WAN interface. Is this what I should expect and what is the reason for this i.e. does it constitute a DNS leak and if so who would be seeing this?
If there are any others using unbound via the VPN, are you getting the same results?
I get the same results whether I set VPN to exclusive or disabled and as discussed in the threads above, if I route unbound via the WAN then both sender and recipient include the WAN address, as expected.
While I can see that the VPN is showing as the sender for unbound, the recipient is still showing as the WAN interface. Is this what I should expect and what is the reason for this i.e. does it constitute a DNS leak and if so who would be seeing this?
If there are any others using unbound via the VPN, are you getting the same results?
Code:
WAN DNS: 127.0.1.1
DHCP DNS: 127.0.1.1
DoT DNS: 1.1.1.1, 1.0.0.1 (Strict)
OVPN5 IP/DNS Config/Redirect Internet: 10.8.0.4/Disabled/VPN Director
Active DNS (Do53/DoT) UDP/TCP Connections
Do53 (plaintext) routed over the WAN
DoT (ciphertext) routed over the WAN
Do53/DoT NOT routed over the WAN (loopback, local, or VPN)
v-------------- sender ---------------v v------------- recipient -------------v
udp src=10.5.6.115 dst=10.5.6.1 dport=53 src=10.5.6.1 dst=10.5.6.115
udp src=10.5.6.116 dst=10.5.6.1 dport=53 src=10.5.6.1 dst=10.5.6.116
udp src=10.5.6.120 dst=10.5.6.1 dport=53 src=10.5.6.1 dst=10.5.6.120
udp src=10.5.6.169 dst=1.1.1.1 dport=53 src=10.5.6.1 dst=10.5.6.169
udp src=10.8.0.4 dst=172.83.92.11 dport=53 src=172.83.92.11 dst=x.x.x.x
udp src=10.8.0.4 dst=192.190.7.250 dport=53 src=192.190.7.250 dst=x.x.x.x
udp src=10.8.0.4 dst=192.190.7.251 dport=53 src=192.190.7.251 dst=x.x.x.x
udp src=10.8.0.4 dst=192.33.14.30 dport=53 src=192.33.14.30 dst=x.x.x.x
udp src=10.8.0.4 dst=192.41.162.30 dport=53 src=192.41.162.30 dst=x.x.x.x
udp src=10.8.0.4 dst=192.48.79.30 dport=53 src=192.48.79.30 dst=x.x.x.x
udp src=10.8.0.4 dst=192.5.6.30 dport=53 src=192.5.6.30 dst=x.x.x.x
udp src=10.8.0.4 dst=192.52.178.30 dport=53 src=192.52.178.30 dst=x.x.x.x
udp src=10.8.0.4 dst=192.54.112.30 dport=53 src=192.54.112.30 dst=x.x.x.x
udp src=10.8.0.4 dst=192.55.83.30 dport=53 src=192.55.83.30 dst=x.x.x.x
udp src=10.8.0.4 dst=198.181.117.5 dport=53 src=198.181.117.5 dst=x.x.x.x
udp src=10.8.0.4 dst=216.252.166.10 dport=53 src=216.252.166.10 dst=x.x.x.x
udp src=10.8.0.4 dst=64.208.140.26 dport=53 src=64.208.140.26 dst=x.x.x.x
udp src=10.8.0.4 dst=64.4.48.205 dport=53 src=64.4.48.205 dst=x.x.x.x
udp src=127.0.0.1 dst=127.0.1.1 dport=53 src=127.0.1.1 dst=127.0.0.1
tcp src=x.x.x.x dst=1.0.0.1 dport=853 src=1.0.0.1 dst=x.x.x.x
tcp src=x.x.x.x dst=1.1.1.1 dport=853 src=1.1.1.1 dst=x.x.x.xI get the same results whether I set VPN to exclusive or disabled and as discussed in the threads above, if I route unbound via the WAN then both sender and recipient include the WAN address, as expected.
eibgrad
Part of the Furniture
There isn't quite enough information there for me to explain it.
Where is Unbound running? On the router? Some other LAN device?
What specifically are your policy rules?
Do you have anything in the custom config field of the OpenVPN client?
You might was well dump the routing system so we can see the full context (hiding your public IP is fine).
Code:
ip rule
ip route
ip route show table ovpnc5eibgrad
Part of the Furniture
@archiel
Also, how does Unbound fit into your DNS handling? I can understand the WAN and DHCP using DNSMasq, and DNSMasq being bound to the DoT server (Stubby @ 127.0.1.1), but I don't see how Unbound itself is bound to any specific clients. I don't use Unbound, so you need to be more specific in that regard.
Also, how does Unbound fit into your DNS handling? I can understand the WAN and DHCP using DNSMasq, and DNSMasq being bound to the DoT server (Stubby @ 127.0.1.1), but I don't see how Unbound itself is bound to any specific clients. I don't use Unbound, so you need to be more specific in that regard.
Unbound is run on the router (RT-AX88U) with default settings (recursive DNS)
Until very recently I did not use DoT, only added these and blanked the non-DoT DNS servers (OpenDNS) after reading this thread and seeing the 'ET phone home' messages going out via the WAN. DNS Filtering is set to ON and the default is Router
This is what I think should be happening (happy to be corrected)
When the router is booted is runs its initial DNS enquires through whatever is setup in the WAN > Internet connection page - in my case the DOT servers, previously the OpenDNS servers.
Once Unbound has loaded then all client DNS queries are run though it, unless specifically excluded (e.g. via VPN client if set to exclusive or the client is directed elsewhere through DNS Filtering). All WAN queries go via the DoT servers.
If Unbound is not set to use the VPN, the I see (in red) all the client queries from WAN -> Unbound selected DNS servers & Unbound selected DNS servers -> WAN
If I change the Unbound settings to use a VPN then I see client queries from VPN -> Unbound selected DNS servers & Unbound selected DNS servers -> WAN (still in red)
Code:
0: from all lookup local
11010: from 10.5.6.150 lookup ovpnc5
32766: from all lookup main
32767: from all lookup default
Code:
default via 176.253.204.1 dev eth0
10.0.0.0/8 dev br0 proto kernel scope link src 10.5.6.10
10.8.0.0/24 dev tun15 proto kernel scope link src 10.8.0.4
10.5.6.0/24 dev br0 proto kernel scope link src 10.5.6.1
10.88.0.0/24 dev tun21 proto kernel scope link src 10.88.0.1
127.0.0.0/8 dev lo scope link
xxx.xxx.xxx.0/22 dev eth0 proto kernel scope link src xxx.xxx.xxx.143
xxx.xxx.xxx.1 dev eth0 proto kernel scope link
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.2
Code:
default via 10.8.0.1 dev tun15
10.0.0.0/8 dev br0 proto kernel scope link src 10.5.6.10
10.8.0.0/24 dev tun15 proto kernel scope link src 10.8.0.4
10.5.6.0/24 dev br0 proto kernel scope link src 10.5.6.1
10.88.0.0/24 dev tun21 proto kernel scope link src 10.88.0.1
127.0.0.0/8 dev lo scope link
xxx.xxx.xxx.0/22 dev eth0 proto kernel scope link src xxx.xxx.xxx.143
xxx.xxx.xxx.1 dev eth0 proto kernel scope link
yyy.yyy.yyy.yyy via xxx.xxx.xxx.1 dev eth0
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.2Note: 10.5.6.10 is the pixelserv address & yyy.yyy.yyy.yyy is the NordVPN server
eibgrad
Part of the Furniture
@archiel
You're still NOT telling me *how* the Unbound server is getting called! I don't use Unbound. I have no idea how you configured it. Did you use some tutorial? Was it part of an automatic install? Does it alter DNSMasq to have it call the Unbound server rather than the DoT server(s)? All I know is there is this new DNS server in the mix called Unbound, but I haven't a CLUE how it ends up being called/referenced. All I know about is the WAN and DHCP (DNSMasq) settings, and how the WLAN/LAN clients are (by default) configured to use DNSMasq. How does Unbound get into the picture?
P.S. I just noticed AMTM is capable of installing Unbound. Did you use this? Which option? Integrate w/ Stubby or Integrate w/ DoT? I want to make sure I'm configured similarly so I can determine how all these pieces are linked together.
I'm also hoping I won't have to become an Unbound expert to answer your question. Seems the discussion threads on this forum are might lengthy at this point.
www.snbforums.com
www.snbforums.com
You're still NOT telling me *how* the Unbound server is getting called! I don't use Unbound. I have no idea how you configured it. Did you use some tutorial? Was it part of an automatic install? Does it alter DNSMasq to have it call the Unbound server rather than the DoT server(s)? All I know is there is this new DNS server in the mix called Unbound, but I haven't a CLUE how it ends up being called/referenced. All I know about is the WAN and DHCP (DNSMasq) settings, and how the WLAN/LAN clients are (by default) configured to use DNSMasq. How does Unbound get into the picture?
P.S. I just noticed AMTM is capable of installing Unbound. Did you use this? Which option? Integrate w/ Stubby or Integrate w/ DoT? I want to make sure I'm configured similarly so I can determine how all these pieces are linked together.
I'm also hoping I won't have to become an Unbound expert to answer your question. Seems the discussion threads on this forum are might lengthy at this point.
Unbound - Authoritative Recursive Caching DNS Server
Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. Late 2019, Unbound has been rigorously audited, which means that the code base is more resilient than ever. To help increase online privacy...
www.snbforums.com
Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server)
This thread is for the discussion topic : unbound_manager script. As per the GitHub Hints/Tips: Differences between the operational modes Easy mode Advanced Mode 'Easy' mode - you have limited Install options: i.e. Advanced Options Stubby Integration DoT installs are not available...
www.snbforums.com
Last edited:
eibgrad
Part of the Furniture
Putting aside Unbound for a moment, the main routing table doesn't look right.
Notice the first route is a /8, which means all the other 10.x.x.x/24 routes lie within its own scope! Even the OpenVPN server (10.88.0.0/24). This is the kind of stuff that leads to problems. There are so many 10.x.x.x networks, I'm not always sure where they are coming from. I assume 10.5.6.0/24 is your actual WLAN/LAN IP network (br0). But where did 10.0.0.0/8 (br0) come from? I also see 192.168.2.0/24 defined on the WAN (eth0), suggesting this is a double NAT situation.
This is probably one situation where it would have helped had you only obscured the actual public IP on the WAN (if there even is a public IP on the WAN) because its hard to follow what's happening on the router based solely on examining the routing table. But as soon as I see overlapping IP networks, that raises a red flag.
Code:
default via 176.253.204.1 dev eth0
10.0.0.0/8 dev br0 proto kernel scope link src 10.5.6.10
10.8.0.0/24 dev tun15 proto kernel scope link src 10.8.0.4
10.5.6.0/24 dev br0 proto kernel scope link src 10.5.6.1
10.88.0.0/24 dev tun21 proto kernel scope link src 10.88.0.1
127.0.0.0/8 dev lo scope link
xxx.xxx.xxx.0/22 dev eth0 proto kernel scope link src xxx.xxx.xxx.143
xxx.xxx.xxx.1 dev eth0 proto kernel scope link
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.2Notice the first route is a /8, which means all the other 10.x.x.x/24 routes lie within its own scope! Even the OpenVPN server (10.88.0.0/24). This is the kind of stuff that leads to problems. There are so many 10.x.x.x networks, I'm not always sure where they are coming from. I assume 10.5.6.0/24 is your actual WLAN/LAN IP network (br0). But where did 10.0.0.0/8 (br0) come from? I also see 192.168.2.0/24 defined on the WAN (eth0), suggesting this is a double NAT situation.
This is probably one situation where it would have helped had you only obscured the actual public IP on the WAN (if there even is a public IP on the WAN) because its hard to follow what's happening on the router based solely on examining the routing table. But as soon as I see overlapping IP networks, that raises a red flag.
I installed following this thread Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) | SmallNetBuilder Forums (snbforums.com) and also follow Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) - General questions / discussion thread 2 | SmallNetBuilder Forums (snbforums.com).
I installed from AMTM using the default settings + unbound logging, CPU/Memory Tweaks, GUI statistics, unbound-control FAST response and (now) unbound requests via VPN Client. I had added IPv6 support, but reversed this out while testing the DNS-monitoring script. Changes to the default installation can be from AMTM (basic setting only), by running unbound_manager advanced from a SSH window or by editing /opt/var/lib/unbound/unbound.conf directly or in /opt/share/unbound/configs/unbound.conf.add. I use WinSCP as I find it easiest to use.
I have not used the integrate w/stubby or w/DoT options - my understanding (quite possibly wrong) were that these are if you want to route all the client DNS requests via stubby / DoT to the upstream DNS servers rather than send directly via the WAN (or VPN).
This is from setting pixelsrv-tls (within diversion standard) to 10.5.6.10. If I disable pixelsrv and run ip route then
Code:
default via 176.253.204.1 dev eth0
10.8.0.0/24 dev tun15 proto kernel scope link src 10.8.0.4
10.5.6.0/24 dev br0 proto kernel scope link src 10.5.6.1
10.88.0.0/24 dev tun21 proto kernel scope link src 10.88.0.1
127.0.0.0/8 dev lo scope link
176.253.204.0/22 dev eth0 proto kernel scope link src 176.253.204.143
176.253.204.1 dev eth0 proto kernel scope link
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.2As to why pixelsrv needs /8, I am guessing it is so it will work across any other 10.x.x.x subnet (for guest networks, etc.). I would think this can be best answered by @thelonelycoder if you consider it problematic.
eibgrad
Part of the Furniture
Not being a user of Unbound, I don't know either. But what I do know is that when you enable DoT on the WAN, it updates the DNSMasq configuration to point *only* to Stubby (127.0.1.1) for public name resolution. I would *assume* installation of Unbound using the defaults would so the same, i.e., alter DNSMasq to point to *only* itself for public name resolution. And if I'm right, then you have a conflict. Each is assuming exclusive control of public name resolution. And that's why I thought that perhaps the specific option for integration w/ Stubby was part of the Unbound installation options. IOW, to make it compatible w/ Stubby. But if you just take the default Unbound installation and then decide to throw in Stubby for good measure, I don't know what the results will be.
Let's see the contents of the DNSMasq config files and perhaps we can better understanding of what's happening.
Code:
cat /tmp/etc/dnsmasq.conf
cat /tmp/resolv.dnsmasqeibgrad
Part of the Furniture
It's NOT necessarily problematic. There are times when a sophisticated user can use such routing techniques to gain certain behavior. So it's NOT unheard of. But I wanted to know *why* it was there since under typical, normal conditions you wouldn't see this.
For a very brief discussion of the amtm script Unbound-Asuswrt-Merlin/Readme.md at master · MartineauUK/Unbound-Asuswrt-Merlin · GitHub
cat /tmp/resolv.dnsmasq gets server=127.0.1.1
for cat /tmp/etc/dnsmasq.conf, I have removed the DHCP reservation details (dhcp-host=deviceMAC, Set:deviceMAC, devicename, IP reservation). Do you need to see this?
Code:
pid-file=/var/run/dnsmasq.pid
user=nobody
bind-dynamic
interface=br0
interface=pptp*
no-dhcp-interface=pptp*
no-resolv
no-poll
no-negcache
cache-size=0
min-port=4096
domain=MyDomain
expand-hosts
bogus-priv
domain-needed
local=/MyDomain/
dhcp-range=lan,10.5.6.67,10.5.6.254,255.255.255.0,86400s
dhcp-option=lan,3,10.5.6.1
dhcp-option=lan,15,MyDomain
dhcp-option=lan,252,"\n"
dhcp-authoritative
interface=br1
dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s
dhcp-option=br1,3,192.168.101.1
interface=br2
dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s
dhcp-option=br2,3,192.168.102.1
dhcp-host=deviceMAC, Set:deviceMAC, devicename, IP reservation
....
address=/use-application-dns.net/
address=/_dns.resolver.arpa/
dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore
dhcp-script=/sbin/dhcpc_lease
script-arp
edns-packet-max=1280
dhcp-option=lan,42,10.5.6.1 # ntpMerlin
# start of Diversion directives #
address=/0.0.0.0/0.0.0.0
ptr-record=0.0.0.0.in-addr.arpa,0.0.0.0
addn-hosts=/opt/share/diversion/list/blacklist
addn-hosts=/opt/share/diversion/list/blockinglist
log-async
log-queries
log-facility=/opt/var/log/dnsmasq.log
# end of Diversion directives #
server=127.0.0.1#53535eibgrad
Part of the Furniture
Well that DNSMasq config file no longer contains any reference to Stubby (127.0.1.1), as I suspected. All I see is what I presume is Unbound (server=127.0.0.1#53535).
Looking at my own DNSMasq config file w/ DoT enabled, it contains the following ...
Code:
admin@lab-merlin1:/tmp/home/root# cat /tmp/etc/dnsmasq.conf
...
no-resolv
servers-file=/tmp/resolv.dnsmasq
...There are NO server directives because DNSMasq has been told to use /tmp/resolv.dnsmasq, which points to Stubby.
Code:
admin@lab-merlin1:/tmp/home/root# cat /tmp/resolv.dnsmasq
server=127.0.1.1So at the very least, unless Unbound is clever enough to recognize that Stubby is active (which it probably isn't given Stubby was configured *after* Unbound), then I don't see how DoT could even be active for the WLAN/LAN clients. The router itself? Yeah, since it's pointing directly at Stubby (127.0.1.1).
This is why you need to be very careful about how you configure DNS, esp. when you start combining various sources to change its behavior, be it custom servers on the WAN, overrides on the DHCP server, DoT on the WAN, DNS filters (global vs. per client), Unbound, the VPNs w/ their own DNS preferences (Disabled, Exclusive, etc.), yada yada. It can quickly turn into a confusing mess.
As far as connections like the following ...
Code:
udp src=10.8.0.4 dst=172.83.92.11 dport=53 src=172.83.92.11 dst=x.x.x.x... it's difficult to explain since I don't know how Unbound was bound to any network interfaces. Was it to ALL network interfaces? Just the WAN? Just the LAN? You indicated that you configured it to use the VPN, but how? It certainly wasn't done via routing policy.
Code:
0: from all lookup local
11010: from 10.5.6.150 lookup ovpnc5
32766: from all lookup main
32767: from all lookup defaultDid you explicitly bind it to 10.8.0.4 knowing that would be the assigned IP on the NordVPN OpenVPN client? Seems a bit risky to make that assumption. But how that will actually be handled by the routing system depends on the state of the routing table when a routing decision actually needs to be made. And obviously the router choose to route it over the WAN, regardless how you bound Unbound to the network.
Again, all these things messing w/ the routing system have consequences too, and can lead to unexpected behavior.
As far as binding Unbound to the VPN is concerned it is just a matter of setting VPN # (or disable to remove) in unbound_manager advanced.
Unbound then adds the following line in unbound.conf
outgoing-interface: 10.8.3.7 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)
if VPN is disabled then it changes to
#outgoing-interface: 10.8.3.7 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)
From NLnet Labs Documentation - Unbound - unbound.conf.5
outgoing-interface: <ip address or ip6 netblock>
Interface to use to connect to the network. This interface is used to send queries to authoritative servers and receive their
replies. Can be given multiple times to work on several inter-faces. If none are given the default (all) is used. You can
specify the same interfaces in interface: and outgoing-inter-face: lines, the interfaces are then used for both purposes.
Outgoing queries are sent via a random outgoing interface to counter spoofing.
As such it is half working as it (appears to be) using the VPN interface for sending but not receiving.
As I understand it Unbound is intended to intercept any client DNS requests and either respond from its internal cache, or if it cannot (not available, record too old) get the data itself, as explained here: Courtesty of SNB Forum member @dave14305 post 1177
Instead of relying on a Google DNS, Cloudflare, Quad9 or NextDNS, Unbound will let you perform the same DNS functions as those public resolvers. Unbound will deal directly with the authoritative name server (i.e. domain owner) instead of relying on a third-party to do that. You cut out that middle-man. If you only want to use Unbound as another forwarder, it's won't really offer much benefit over the built-in dnsmasq.
When Unbound gets a DNS request from a client, it will not use a single upstream server like you may be used to. Say it gets a request to lookup www.snbforums.com. First it will query the root DNS servers to see what server is the owner of the .com top-level domain. Once it knows that server identity, it will query that one to see which DNS nameserver owns snbforums.com within the .com domain. Once it gets that response, it will query the snbforums.com DNS server to get the IP for www within snbforums.com.
It does all that directly between you and those servers, without sharing your DNS query data with a third-party DNS resolver like the ones I mentioned earlier.
While you can setup Stubby integration (which would mean that Unbound would instead use the designated DoT DNS servers), this would effectively mean than Unbound's only function is to provide the local DNS cache.
Which gets back to the original query as to why the DNS responses are (or appear to be) on the WAN interface, rather than the designated outgoing-interface. Other than that Unbound appears to behaving as expected. When I have some time I will look at tcpdump just in case if it gives any further clues.
Unbound then adds the following line in unbound.conf
outgoing-interface: 10.8.3.7 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)
if VPN is disabled then it changes to
#outgoing-interface: 10.8.3.7 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)
From NLnet Labs Documentation - Unbound - unbound.conf.5
outgoing-interface: <ip address or ip6 netblock>
Interface to use to connect to the network. This interface is used to send queries to authoritative servers and receive their
replies. Can be given multiple times to work on several inter-faces. If none are given the default (all) is used. You can
specify the same interfaces in interface: and outgoing-inter-face: lines, the interfaces are then used for both purposes.
Outgoing queries are sent via a random outgoing interface to counter spoofing.
As such it is half working as it (appears to be) using the VPN interface for sending but not receiving.
As I understand it Unbound is intended to intercept any client DNS requests and either respond from its internal cache, or if it cannot (not available, record too old) get the data itself, as explained here: Courtesty of SNB Forum member @dave14305 post 1177
Instead of relying on a Google DNS, Cloudflare, Quad9 or NextDNS, Unbound will let you perform the same DNS functions as those public resolvers. Unbound will deal directly with the authoritative name server (i.e. domain owner) instead of relying on a third-party to do that. You cut out that middle-man. If you only want to use Unbound as another forwarder, it's won't really offer much benefit over the built-in dnsmasq.
When Unbound gets a DNS request from a client, it will not use a single upstream server like you may be used to. Say it gets a request to lookup www.snbforums.com. First it will query the root DNS servers to see what server is the owner of the .com top-level domain. Once it knows that server identity, it will query that one to see which DNS nameserver owns snbforums.com within the .com domain. Once it gets that response, it will query the snbforums.com DNS server to get the IP for www within snbforums.com.
It does all that directly between you and those servers, without sharing your DNS query data with a third-party DNS resolver like the ones I mentioned earlier.
While you can setup Stubby integration (which would mean that Unbound would instead use the designated DoT DNS servers), this would effectively mean than Unbound's only function is to provide the local DNS cache.
Which gets back to the original query as to why the DNS responses are (or appear to be) on the WAN interface, rather than the designated outgoing-interface. Other than that Unbound appears to behaving as expected. When I have some time I will look at tcpdump just in case if it gives any further clues.
eibgrad
Part of the Furniture
We need to make an important distinction here.
The binding of the inbound/outbound network interfaces within the app itself (Unbound in this case) are NOT routing decisions! What these do is tell the application how it should interface w/ the available local network interfaces on the current device. On the inbound side, it tells the application on which network interface(s) is should listen for connection requests. On the outbound side, it tells the application which network interface(s) it should use in initiating its own requests. But this does NOT determine how traffic will be routed outside that device! Only the routing system determines that. The routing system looks at the destination IP of the network request (regardless where it came from) and based on the state of the routing tables, determines which route is best suited for the purpose.
The impression I'm getting is that you're treating these inbound/outbound network interface configuration options as if THEY determined the routing. They do NOT! Again, all they do is determine how the app interacts w/ the available local network interfaces in terms of receiving and sending network messages within the app itself. That's why you can bind the app to various *local* network interfaces on the router, but it's only for the purposes of how that app interacts w/ the router. Ultimately the routing system determines how traffic is routed outside the router.
The only thing that surprised me in the output from the DNS monitoring script was the fact the src field on the sender was from the VPN, NOT that the recipient was indicating the routing was out the WAN. But based on these recent posts, I now see why. In contrast, YOU were surprised the routing was out the WAN when you had bound the app (Unbound) to the VPN. But as I said, those are two different things. How the app is bound to the local network interfaces is NOT the same thing as how traffic from the app is routed outside the router. When it comes to the internet, unless you have established static routes that bind specific destination IPs to the WAN or VPN, then internet access will *always* be determined by the current default gateway, regardless how any given app is bound *locally* to the various available network interfaces.
ZebMcKayhan
Very Senior Member
@archiel for some inspiration:
when I setup unbound to go out Wireguard I don't get the nifty scripted vpn directives. Instead I made it manually, and differently:
https://github.com/ZebMcKayhan/WireguardManager#setup-transmission-andor-unbound-to-use-wg-client
basically use outgoing-interface set to router lan ip (192.168.1.1) then create a route rule in wgm (for you it would be in VPNDirector I presume) to route 192.168.1.1 to vpn.
In Wgm case, the policy routing table are sparse (dont know how they are with OpenVpn) so it would need to be completed with a higher priority rule for packets with destinations of this subnet to use main routing table, which means WAN (misleading name for this purpose).
The reason for this completing rule is that whenever the router wants to talk to lan clients, it will use this adress and there might not be a route to it in the policy routing table.
Thats the source part of the routing. Then you need to take care of any discrepancy in the policy routing table, as @eibgrad points out. Thats the destination part of the routing.
This approach works really nicely for me and to quote myself "green as far as the eye can see" (as long as I can keep my daughter off the guest network).
//Zeb
when I setup unbound to go out Wireguard I don't get the nifty scripted vpn directives. Instead I made it manually, and differently:
https://github.com/ZebMcKayhan/WireguardManager#setup-transmission-andor-unbound-to-use-wg-client
basically use outgoing-interface set to router lan ip (192.168.1.1) then create a route rule in wgm (for you it would be in VPNDirector I presume) to route 192.168.1.1 to vpn.
In Wgm case, the policy routing table are sparse (dont know how they are with OpenVpn) so it would need to be completed with a higher priority rule for packets with destinations of this subnet to use main routing table, which means WAN (misleading name for this purpose).
The reason for this completing rule is that whenever the router wants to talk to lan clients, it will use this adress and there might not be a route to it in the policy routing table.
Thats the source part of the routing. Then you need to take care of any discrepancy in the policy routing table, as @eibgrad points out. Thats the destination part of the routing.
This approach works really nicely for me and to quote myself "green as far as the eye can see" (as long as I can keep my daughter off the guest network).
//Zeb
Last edited:
Hi @eibgrad and @ZebMcKayhan. Thank you both for your replies, I think it is fair to say that I am moving from 'did not know that I did not know' to 'knowing that I do not know' but I am still new to this (and v confused).
If I have understood anything it is that using outgoing-interface in Unbound works as far as determining how the DNS requests are sent, but in order to have the replies via the VPN/avoid the WAN there need to be specific routing instructions. If this is correct then it is a matter of how would I determine what these instructions would be and how / where would they go.
There would seem to be at least 3 ways of approaching this - adding rules in VPN director, adding static routes in LAN or editing directly, but I need some guidance on what, how and where. For instance in the wgm link @ZebMcKayhan discusses adding
and above
but what would be the analogous rules in VPN director (assuming this would be the right place. Currently my sole rule is
and would the order be relevant.
With regard to my current routes (from ip route)
@eibgrad mentioned in #130 above that
to allow me to check its status from the LAN.
If I have understood anything it is that using outgoing-interface in Unbound works as far as determining how the DNS requests are sent, but in order to have the replies via the VPN/avoid the WAN there need to be specific routing instructions. If this is correct then it is a matter of how would I determine what these instructions would be and how / where would they go.
There would seem to be at least 3 ways of approaching this - adding rules in VPN director, adding static routes in LAN or editing directly, but I need some guidance on what, how and where. For instance in the wgm link @ZebMcKayhan discusses adding
and above
but what would be the analogous rules in VPN director (assuming this would be the right place. Currently my sole rule is
and would the order be relevant.
With regard to my current routes (from ip route)
Code:
default via 176.253.204.1 dev eth0
10.8.0.0/24 dev tun15 proto kernel scope link src 10.8.0.4
10.5.6.0/24 dev br0 proto kernel scope link src 10.5.6.1
10.88.0.0/24 dev tun21 proto kernel scope link src 10.88.0.1
127.0.0.0/8 dev lo scope link
176.253.204.0/22 dev eth0 proto kernel scope link src 176.253.204.143
176.253.204.1 dev eth0 proto kernel scope link
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.2For clarity, there is no double NAT. I am connected to my ISP via a Vigor 130 VDSL2 modem (not a router) I have added
Code:
#!/bin/sh
if [ "$2" = "connected" ]; then
ifconfig $(nvram get wan"$1"_ifname):1 192.168.2.2
fiSimilar threads
Similar threads
Similar threads
-
-
Bandwidth Monitor always ON even with Apps Analysis OFF AX6000 3004.388.5
- Started by JPP PPJ
- Replies: 2
-
-
-
Upgraded to AX86, some questions about Traffic Monitor and Windguard
- Started by Wafflestyx
- Replies: 2
-
-
-
-
-
Would any of this make my browsing more secure? (WAN DNS settings)
- Started by Rob Q
- Replies: 20
Latest threads
-
Diversion Diversion and Ubisoft Connect - how to find out what is the problematic block?
- Started by RouterNoob93
- Replies: 0
-
1.5Gb fiber connection with 3 mesh nodes. Clients getting ~500Mbps. Setting or nature of AIMesh?
- Started by neil0311
- Replies: 2
-
-
[SOLUTION] WAN_Connection: ISP's DHCP did not function properly- Started by garycnew
- Replies: 2
-
RT-AX57 occasionally broadcasting hidden SSID
- Started by Salting
- Replies: 1
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!