I am running Diversion & Unbound; but thinking of removing Diversion since Unbound does ad-blocking as well.
Few questions...
1) Diversion allows to choose different Adblock lists (minimal, small, standard, medium, large) - can the same be done with Unbound? Some detailed instructions would be helpful.
2) It is very easy to find a blocked site in Diversion; especially by specific IP address (Diversion, f, 4) - does Unbound do something similar? Can someone please explain in some detail - I have read the forum posts but can’t find detail or instructions to find blocked domains by a particular IP.
Thanks...
I believe the answer to your first question is answered in the first post of this thread. And quite possibly the second question is as well. You may need to roll up your sleeves and dive into unbound_manager advanced
I believe the answer to your first question is answered in the first post of this thread. And quite possibly the second question is as well. You may need to roll up your sleeves and dive into unbound_manager advanced
Sorry to ask again. I have gone through the first thread as well as advanced menu - but cannot find the answer.
I cannot figure out "how to find out in Unbound which domains are being blocked for a particular client IP address?".
As a comparison, in Diversion, I can launch Diversion, F, 4, <Client IP address>. This starts a tail-f of the log but only shows the blocked domains of the specific client IP.
I can then exit out of tail and in Diversion, el, 1, 1, <domain name identified from the tail-f>
Process the lists; and the domain is whitelisted.
How do I replicate this behaviour in Unbound?
- Finding out for a particular client IP what is 'being blocked'?
- Adding the 'identified blocked domain' to whitelist?
What exact commands do I launch or menu options do I choose in Unbound?
If unbound logging is enabled, use command 'l' to view the log in real-time .....(if you have enabled @juched's statistics GUI, then you may see the results there or either grep the unbound log or create an SQL query against the database)
Unfortunately, by default unbound receives DNS requests from dnsmasq, (rather than individual LAN devices) so the source IP will always be 127.0.0.1.
e.g. an unidentified LAN device is requesting a blocked ('always_nxdomain') domain 'ipid.shat.net'
Code:
E:Option ==> l
/opt/var/lib/unbound/unbound.log Press CTRL-C to stop
Sep 24 19:07:29 unbound[8874:0] query: 127.0.0.1 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] info: ipid.shat.net. always_nxdomain 127.0.0.1@9176 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] query: 127.0.0.1 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] info: ipid.shat.net. always_nxdomain 127.0.0.1@7114 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] query: 127.0.0.1 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] info: ipid.shat.net. always_nxdomain 127.0.0.1@22641 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] query: 127.0.0.1 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] info: ipid.shat.net. always_nxdomain 127.0.0.1@17216 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] query: 127.0.0.1 ipid.shat.net. A IN
Sep 24 19:07:29 unbound[8874:0] info: ipid.shat.net. always_nxdomain 127.0.0.1@45786 ipid.shat.net. A IN
Sep 24 19:07:30 unbound[8874:0] query: 127.0.0.1 www.google.com. AAAA IN
Sep 24 19:07:30 unbound[8874:0] query: 127.0.0.1 www.google.com. A IN
Sep 24 19:07:31 unbound[8874:0] query: 127.0.0.1 cdn.samsungcloudsolution.com. A IN
Sep 24 19:07:33 unbound[8874:0] query: 127.0.0.1 www.google.com. A IN
If you need to have unbound report the actual IP of the LAN device then you will need to disable dnsmasq
Use 'Advanced' command 'dnsmasq disable'
e.g. unbound log will now identify/disclose LAN device 10.88.8.120 is requesting blocked ('always_nxdomain') domain 'ipid.shat.net'
Code:
e = Exit Script [?]
A:Option ==> l
/opt/var/lib/unbound/unbound.log Press CTRL-C to stop
Sep 24 19:20:25 unbound[26604:0] query: 127.0.0.1 www.google.com. AAAA IN
Sep 24 19:20:25 unbound[26604:0] query: 127.0.0.1 www.google.com. A IN
Sep 24 19:20:27 unbound[26604:0] query: 10.88.8.120 ipid.shat.net. A IN
Sep 24 19:20:27 unbound[26604:0] info: ipid.shat.net. always_nxdomain 10.88.8.120@2360 ipid.shat.net. A IN
Sep 24 19:20:27 unbound[26604:0] query: 10.88.8.120 ipid.shat.net. A IN
Sep 24 19:20:27 unbound[26604:0] info: ipid.shat.net. always_nxdomain 10.88.8.120@2360 ipid.shat.net. A IN
Sep 24 19:20:28 unbound[26604:0] query: 10.88.8.140 cdn.samsungcloudsolution.com. A IN
Sep 24 19:20:29 unbound[26604:0] query: 10.88.8.251 dns.msftncsi.com. A IN
Sep 24 19:20:33 unbound[26604:0] query: 10.88.8.140 cdn.samsungcloudsolution.com. A IN
managed to resolve vpn query issue. the error was when i selected the vpn dns query option worked fine but not really! During the dns query, the ip address and host assigned by the ISP appeared. not vpn ip. I used it this way for a long time and then I realized the problem was caused by the settings of the vpn client. The Force Internet traffic through tunnel set policy rules was set because I used 1 client on this vpn client. i changed NO and my dns ip address became vpn . I use 2 vpn providers on one with only the dns resolution going on the other on the internet. So if the policy rules in the setting of unbound vpn is not working properly.
managed to resolve vpn query issue. the error was when i selected the vpn dns query option worked fine but not really! During the dns query, the ip address and host assigned by the ISP appeared. not vpn ip. I used it this way for a long time and then I realized the problem was caused by the settings of the vpn client. The Force Internet traffic through tunnel set policy rules was set because I used 1 client on this vpn client. i changed NO and my dns ip address became vpn . I use 2 vpn providers on one with only the dns resolution going on the other on the internet. So if the policy rules in the setting of unbound vpn is not working properly.
unbound_manager simply attempts to identify the IP address of the appropriate VPN interface...
e.g. crudely using
Code:
ip route | grep "dev tun1"${VPN_ID}
then configures 'unbound.conf' with the resulting appropriate IP address.
Back in April 2020, @Chris0815 shared/proposed his method, and posted several informative explanations such as this
and is/was happy with the pros and cons of his method.
Clearly in the interim 6 months, unbound has been upgraded (two major releases - 1.10 and 1.11?), so it could be that unbound is now only using the WAN interface?
P.S. I recall you weren't convinced back in April 2020 that @Chris0815's solution worked?
unbound_manager simply attempts to identify the IP address of the appropriate VPN interface...
e.g. crudely using
Code:
ip route | grep "dev tun1"${VPN_ID}
then configures 'unbound.conf' with the resulting appropriate IP address.
Back in April 2020, @Chris0815 shared/proposed his method, and posted several informative explanations such as this
and is/was happy with the pros and cons of his method.
Clearly in the interim 6 months, unbound has been upgraded (two major releases - 1.10 and 1.11?), so it could be that unbound is now only using the WAN interface?
P.S. I recall you weren't convinced back in April 2020 that @Chris0815's solution worked?
it successfully identifies the vpn ip address, this is not the problem. the router's internal vpn rule system is a problem. Now I can see that the traffic on the vpn 2 interface has increased significantly compared to the previous period, now I think it works 100% well.
" However, if you use a VPN Client, then you may opt to force unbound to bind to the VPN tunnel, so all unbound's DNS requests will be via the tunnel, so now your VPN assigned IP will be shown in a DNS Leak test. "
How do I force unbound to bind to the VPN tunnel? Because even when I use vpn client, it shows my WAN IP as my DNS server and not the vpn's IP.
" However, if you use a VPN Client, then you may opt to force unbound to bind to the VPN tunnel, so all unbound's DNS requests will be via the tunnel, so now your VPN assigned IP will be shown in a DNS Leak test. "
How do I force unbound to bind to the VPN tunnel? Because even when I use vpn client, it shows my WAN IP as my DNS server and not the vpn's IP.
On the VPN page? I have policy rules set to "Policy Rules (strict) " to force only specific devices through vpn. I set it to policy rules without strict and still it shows my wan IP.
On DNS conf on the vpn page I set "Strict" or should I set it to exclusive or maybe disable it?
On the VPN page? I have policy rules set to "Policy Rules (strict) " to force only specific devices through vpn. I set it to policy rules without strict and still it shows my wan IP.
On DNS conf on the vpn page I set "Strict" or should I set it to exclusive or maybe disable it?
just try setting it to NO. and just set the unbound. and YES (all client use vpn) may work, but policy rules can cause confusion. I can only experiment further in the afternoon. But the fact that for me the dns ip changed until then was the wan ip.
I redirected all traffic to a single vpn server (client 1). Accept DNS Configuration: disabled, Force Internet traffic through tunnel: yes. I redirected the unbound server to a query via vpn 1. The result is my dns and ip address are the same, no dns leaks, ad blocking works all over the network! Query statistics and cache work well! The system has not worked so well yet. Everything I wanted now works!
there are so many errors that in this form the unbound_ manager advanced in ssh vpn 1 command shows the good internal ip address of tun11 but does not write it to the unbound.conf file and thus does not update it (outgoing-interface: 10.8.8.9). only updates if Force Internet traffic through tunnel: policy rules is set. i don't understand why ??
vpn 1 command shows the good internal ip address of tun11 but does not write it to the unbound.conf file and thus does not update it (outgoing-interface: 10.8.8.9).
If you run unbound_manager with 'debug' , it should produce output to display the two 'sed' commands I use to update the 'out-going-interface' direcective in 'unbound.conf'
Code:
e = Exit Script [?]
A:Debug mode enabledOption ==> vpn 1
+ local ARG2=
+ echo vpn 1
+ wc -w
+ [ 2 -ge 3 ]
+ local ARG=
+ echo vpn 1
+ wc -w
+ [ 2 -ge 2 ]
+ printf %s vpn 1
+ cut -d -f2
+ local ARG=1
+ Unbound_Installed
+ [ -f /opt/var/lib/unbound/unbound.conf ]
+ which unbound-control
+ [ -n /opt/sbin/unbound-control ]
+ echo Y
+ return 0
+ [ Y == Y ]
+ [ 1 != disable ]
+ [ 1 == debug ]
+ AUTO_REPLY9=?
+ echo
+ Option_Use_VPN_Tunnel ? 1
+ local ANS=?
+ local ARG=1
+ local ARG2=
+ [ N != ? ]
+ [ ? == y ]
+ [ N == ? ]
+ [ ? == ? ]
+ echo -e \nDo you want to route unbound requests through VPN Client \e[95m'1'\e[0m tunnel?\n\n\tReply\e[91m 'y' \e[92mor press [Enter] \e[0m to skip
Do you want to route unbound requests through VPN Client '1' tunnel?
Reply 'y' or press [Enter] to skip
+ read -r ANS
y
+ [ y == y ]
+ Use_VPN_Tunnel 1
+ local STATUS=0
+ grep -E ^[#|o].*utgoing-interface: /opt/var/lib/unbound/unbound.conf
+ [ -n # - Add 'outgoing-interface:' template
#outgoing-interface: 100.120.61.55 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY) ]
+ [ 1 = y ]
+ echo 1
+ awk {print $1}
+ local VPN_ID=1
+ local TRACK=
+ local TXT=
+ nvram get vpn_client1_state
+ [ 2 == 2 ]
+ Edit_config_options outgoing-interface: uncomment
+ local FN=/opt/var/lib/unbound/unbound.conf
+ local TO=
+ _quote outgoing-interface:
+ echo outgoing-interface:
+ sed s/[]\/()$*.^|[]/\\&/g
+ local MATCH=outgoing-interface:
+ shift
+ local SEDACTION=-i
+ [ 1 -gt 0 ]
+ local ACTION=uncomment
+ shift
+ [ 0 -gt 0 ]
+ [ -z outgoing-interface: ]
+ grep -Enw [[:space:]]*server: /opt/var/lib/unbound/unbound.conf
+ head -n 1
+ cut -d: -f1
+ local POS=22
+ [ -z ]
+ sed -i 22,$ {/#[[:space:]]*outgoing-interface:/ s/#//1} /opt/var/lib/unbound/unbound.conf
+ ip route
+ grep dev tun11
+ awk {print $NF}
+ local VPN_CLIENT_GW=100.120.59.137
+ [ -n 100.120.59.137 ]
+ sed -i /^outgoing-interface:/ s/[^ ]*[^ ]/100.120.59.137/2 /opt/var/lib/unbound/unbound.conf
+ [ == debug ]
+ echo -e \e[96m\n\tunbound requests via VPN Client \e[95m1 (100.120.59.137)\e[96m tunnel \e[0mENABLED\e[90m
unbound requests via VPN Client 1 (100.120.59.137) tunnel ENABLED
then post the contents of 'unbound.conf' to see if the directive was modified as expected
Code:
grep outgoing-interface /opt/var/lib/unbound/unbound.conf
# - Add 'outgoing-interface:' template
outgoing-interface: 100.120.59.137 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)
No idea why you deliberately chose this contentious statement as your opening gambit
"there are so many errors......."
Not really the way to elicit support is it? but I'd appreciate a comprehensivelist of the "many errors" so I can hang my head in shame.
If you run unbound_manager with 'debug' , it should produce output to display the two 'sed' commands I use to update the 'out-going-interface' direcective in 'unbound.conf'
Code:
e = Exit Script [?]
A:Debug mode enabledOption ==> vpn 1
+ local ARG2=
+ echo vpn 1
+ wc -w
+ [ 2 -ge 3 ]
+ local ARG=
+ echo vpn 1
+ wc -w
+ [ 2 -ge 2 ]
+ printf %s vpn 1
+ cut -d -f2
+ local ARG=1
+ Unbound_Installed
+ [ -f /opt/var/lib/unbound/unbound.conf ]
+ which unbound-control
+ [ -n /opt/sbin/unbound-control ]
+ echo Y
+ return 0
+ [ Y == Y ]
+ [ 1 != disable ]
+ [ 1 == debug ]
+ AUTO_REPLY9=?
+ echo
+ Option_Use_VPN_Tunnel ? 1
+ local ANS=?
+ local ARG=1
+ local ARG2=
+ [ N != ? ]
+ [ ? == y ]
+ [ N == ? ]
+ [ ? == ? ]
+ echo -e \nDo you want to route unbound requests through VPN Client \e[95m'1'\e[0m tunnel?\n\n\tReply\e[91m 'y' \e[92mor press [Enter] \e[0m to skip
Do you want to route unbound requests through VPN Client '1' tunnel?
Reply 'y' or press [Enter] to skip
+ read -r ANS
y
+ [ y == y ]
+ Use_VPN_Tunnel 1
+ local STATUS=0
+ grep -E ^[#|o].*utgoing-interface: /opt/var/lib/unbound/unbound.conf
+ [ -n # - Add 'outgoing-interface:' template
#outgoing-interface: 100.120.61.55 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY) ]
+ [ 1 = y ]
+ echo 1
+ awk {print $1}
+ local VPN_ID=1
+ local TRACK=
+ local TXT=
+ nvram get vpn_client1_state
+ [ 2 == 2 ]
+ Edit_config_options outgoing-interface: uncomment
+ local FN=/opt/var/lib/unbound/unbound.conf
+ local TO=
+ _quote outgoing-interface:
+ echo outgoing-interface:
+ sed s/[]\/()$*.^|[]/\\&/g
+ local MATCH=outgoing-interface:
+ shift
+ local SEDACTION=-i
+ [ 1 -gt 0 ]
+ local ACTION=uncomment
+ shift
+ [ 0 -gt 0 ]
+ [ -z outgoing-interface: ]
+ grep -Enw [[:space:]]*server: /opt/var/lib/unbound/unbound.conf
+ head -n 1
+ cut -d: -f1
+ local POS=22
+ [ -z ]
+ sed -i 22,$ {/#[[:space:]]*outgoing-interface:/ s/#//1} /opt/var/lib/unbound/unbound.conf
+ ip route
+ grep dev tun11
+ awk {print $NF}
+ local VPN_CLIENT_GW=100.120.59.137
+ [ -n 100.120.59.137 ]
+ sed -i /^outgoing-interface:/ s/[^ ]*[^ ]/100.120.59.137/2 /opt/var/lib/unbound/unbound.conf
+ [ == debug ]
+ echo -e \e[96m\n\tunbound requests via VPN Client \e[95m1 (100.120.59.137)\e[96m tunnel \e[0mENABLED\e[90m
unbound requests via VPN Client 1 (100.120.59.137) tunnel ENABLED
then post the contents of 'unbound.conf' to see if the directive was modified as expected
Code:
grep outgoing-interface /opt/var/lib/unbound/unbound.conf
# - Add 'outgoing-interface:' template
outgoing-interface: 100.120.59.137 # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)
I am confused about what should happen when routing DNS requests though a VPN
1. What DNS server should be visible for a device NOT using the VPN
2. What DNS server should be visible for a device using the VPN
Using bowserleaks.com/ip to check for the DNS address.
Enable DNS-based Filtering = Router
unbound set to use VPN 5
On the VPN 5, I set Policy Rules = Strict (with a list of devices using the VPN) and tested with both Accept DNS = Exclusive and Disabled
If Accept DNS = Exclusive then
Device not using VPN: DNS = Router IP address
Device using VPN: DNS = VPN assigned IP address
If Accept DNS = Disabled then
Device not using VPN: DNS = Router IP address
Device using VPN: DNS = Router assigned IP address
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.