Unbound Understanding Unbound...

[Jumpstarter]

You remind me of another member named Sam. Quite a coincidence. I’m getting senile, perhaps.

You remind me of another user named @dave4873904 or even @DaveSANYYZ, but a lot of coincidence Indeed between you three.. Perhaps senility is plaguing us all. I guess if you wrote the tutorial, then you would no longer be spelunking these threads.

 

[Viktor Jaep]

OK so good news... the @Martineau Mod/Swinson script appears to be working... check it out!

Before... this is with Unbound running by default, having the vpn=disable switch active. You'll noticed WAN IP is the sender and the recipient.

After a bunch of trial and error... I got this script working. Here's some instructions for others who may want to try! In 3 easy steps!

1.) First step, make sure Unbound is installed and working with default settings.

2.) To get Unbound to send/receive over VPN, it required the creation of the following files:
* /jffs/scripts/ nat-start
* /jffs/scripts/ openvpn-event (*see code below)
* /jffs/addons/unbound/ unbound_DNS_via_OVPN.sh
* chmod 0755 all of these files. (Just incase!)
* and a reboot

Code needed for the "/jffs/scripts/openvpn-event" file:

#!/bin/sh

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start &
[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-pre-down' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &

3.) Once the router booted up, VPNMON-R2 automatically established its VPN connection. Once an openvpn event hits (like getting the VPN connected), it will trigger the unbound_DNS_via_OVPN.sh, which will run its scripts, trigger Unbound itself... and voila, results below. You'll notice the VPN IP is now the sender and recipient!

Checking dnscheck.tools... all looks clean!

Now.... how to integrate this into VPNMON-R2!!! Almost feel like absorbing the @Martineau/Swinson script in order to make things easier... which would then also need to include the various nat-start/vpnclientX-route-blah-blah scripts... Dunno. Very much on the fence at this point. I think I'll keep an eye on things, and see if it's worth including.

 

[Viktor Jaep]

Just have to say, standing back, admiring the technology and complexity of it all... but being your own DNS resolver while hiding plaintext port 53 queries to root, TLD, and authoritative DNS servers from your own ISP is freaking cool.

And btw, @dave14305 ... this statement is now showing valid port 53 calls going over VPN... and eth0 is not showing any of these returning over that interface.

tcpdump -i tun12 -n udp and dst port 53

I really appreciate all your help and troubleshooting, and suggestions to get this working, @SomeWhereOverTheRainBow, @chongnt, @dave14305, @bennor, @Tech9, @Twiglets and anyone else I may have left out!

 

[chongnt]

...snipped...

2.) To get Unbound to send/receive over VPN, it required the creation of the following files:
* /jffs/scripts/ nat-start
* /jffs/scripts/ vpnclientX-route-up (from 1-5)
* /jffs/scripts/ vpnclientX-route-pre-down (from 1-5)
* /jffs/scripts/ unbound_DNS_via_OVPN.sh
* and a reboot

(Not sure if it was necessary, but I also added a #!/bin/sh to each of the route-up/pre-down files... also, I chmod 0755'd all of these files. Just incase!)

Now.... how to integrate this into VPNMON-R2!!! Almost feel like absorbing the @Martineau/Swinson script in order to make things easier... which would then also need to include the various nat-start/vpnclientX-route-blah-blah scripts... Dunno. Very much on the fence at this point. I think I'll keep an eye on things, and see if it's worth including.

Just an idea, perhaps can make use of the existing /jffs/scripts/openvpn-event script. From openvpn-event, call a single script to perform the first 3 asterisk tasks. Maybe no need to edit nat-start and create all the route-up/route-pre-down scripts.

Here is another great script by @eibgrad that I use. This is for openvpn server event. I also make a copy for openvpn client event based on this script.

[SOLVED] OpenVPN server and Client not allowed at same time?

I have both OpenVPN server and OpenVPN client configs in my router, and I use them for different purposes. I have noticed that if I am connected by client to a remote vpn server, if I connect from outside my lan to my openVPN server on my router that I am unable to get to any internal machine...

www.snbforums.com

 

[chongnt]

@Viktor Jaep , good to see that your sender source IP is exactly your VPN IP. This is the part which I did not get it to show up properly. I manually set out-going interface to 192.168.1.1. What is your configuration for this parameter? Say later you route to another vpn client, does the outgoing-interface changed accordingly? Do you need to restart unbound?

A:Option ==> oq outgoing-interface

unbound-control 'outgoing-interface' '192.168.1.1'

 

[Viktor Jaep]

@Viktor Jaep , good to see that your sender source IP is exactly your VPN IP. This is the part which I did not get it to show up properly. I manually set out-going interface to 192.168.1.1. What is your configuration for this parameter? Say later you route to another vpn client, does the outgoing-interface changed accordingly? Do you need to restart unbound?

A:Option ==> oq outgoing-interface

unbound-control 'outgoing-interface' '192.168.1.1'

My outgoing-interface is being set dynamically to the VPN internal IP... like 10.8.1.2.

When you run the "unbound_dns_via_ovpn.sh 2 stop" command, it will actually # comment it out... Then when you run the "unbound_dns_via_ovpn.sh 4 start" command, it will launch unbound, and cause it to dynamically insert the latest VPN IP for the given slot. At least that seems to be what's happening for me!

I'm not even sending unbound_manager commands any longer. Just the "unbound_dns_via_ovpn.sh" script commands.

 

[chongnt]

My outgoing-interface is being set dynamically to the VPN internal IP... like 10.8.1.2.

When you run the "unbound_dns_via_ovpn.sh 2 stop" command, it will actually # comment it out... Then when you run the "unbound_dns_via_ovpn.sh 4 start" command, it will launch unbound, and cause it to dynamically insert the latest VPN IP for the given slot. At least that seems to be what's happening for me!

I'm not even sending unbound_manager commands any longer. Just the "unbound_dns_via_ovpn.sh" script commands.

Do you mean in /opt/var/lib/unbound/unbound.conf?
#outgoing-interface: xxx.xxx.xxx.xxx # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)

I need to review the script I use and see if I missed out anything.
If you run this before and after re-route to another vpn client, does unbound uptime refresh? I would like to figure out if an unbound restart is triggered in the process.
unbound-control status | grep uptime

 

[Viktor Jaep]

Do you mean in /opt/var/lib/unbound/unbound.conf?
#outgoing-interface: xxx.xxx.xxx.xxx # v1.08 Martineau Use VPN tunnel to hide Root server queries from ISP (or force WAN ONLY)

That's it!

I need to review the script I use and see if I missed out anything.
If you run this before and after re-route to another vpn client, does unbound uptime refresh? I would like to figure out if an unbound restart is triggered in the process.
unbound-control status | grep uptime

Yeah... It looks like it restarts unbound anytime there's a .conf change. I didn't modify anything. Everything is vanilla.

 

[chongnt]

That's it!


Yeah... It looks like it restarts unbound anytime there's a .conf change. I didn't modify anything. Everything is vanilla.

Great. Thanks for the info.
I must have edited something then. My unbound uptime does not refresh when I bind/unbind it to vpn, it just keep running. Maybe something I done to avoid unbound restart in order to preserve the cache, I cannot remember now.

Update:
Found it. I skipped the call_unbound_manager function in the script. So this is not run:
/jffs/addons/unbound/unbound_manager.sh vpn="$1"

 

[Viktor Jaep]

Great. Thanks for the info.
I must have edited something then. My unbound uptime does not refresh when I bind/unbind it to vpn, it just keep running. Maybe something I done to avoid unbound restart in order to preserve the cache, I cannot remember now.

I believe on an unbound restart, it saves and reloads the cache? I could be mistaken though ... still learning/understanding this thing! Lol

If you want me to share my .conf, I'd be happy to?

 

[chongnt]

I believe on an unbound restart, it saves and reloads the cache? I could be mistaken though ... still learning/understanding this thing! Lol

If you want me to share my .conf, I'd be happy to?

@Martineau has a script to do it. Basically a cronjob is used to keep saving the cache, and I reload it in post-mount script during a router reboot. I am not sure if just unbound restart alone will trigger the cache restoration.

Thanks for the offer. I think my unbound.conf should be ok. I only made changes on /opt/share/unbound/configs/unbound.conf.add

 

[chongnt]

Oh yeah, the dump cache feature is available. It seems to only restore cache during router reboot.

Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) - General questions / discussion thread 2

Sorry but I cannot see how to get the Advanced menu. from the Readme on Github

www.snbforums.com

Update:
Indeed unbound restart will restore the cache by itself.

A:Option ==> rs

11:26:12 Checking 'unbound.conf' etc. for valid Syntax.....
11:26:12 Saving unbound cache to '/opt/share/unbound/configs/cache.txt' msg.cache=5266/1421 rrset.cache=9889/5100
11:26:12 Requesting unbound (S61unbound) restart.....
 Shutting down unbound...              done.
 Starting unbound...              done.
11:26:14 Checking status, please wait.....
11:26:16 Restoring unbound cache from '/opt/share/unbound/configs/cache.txt' (2023-05-06 11:26:12) msg.cache=0/1421 rrset.cache=0/5100
11:26:17 unbound OK

 

[Viktor Jaep]

Oh yeah, the dump cache feature is available. It seems to only restore cache during router reboot.

Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) - General questions / discussion thread 2

Sorry but I cannot see how to get the Advanced menu. from the Readme on Github

www.snbforums.com

Update:
Indeed unbound restart will restore the cache by itself.

A:Option ==> rs

11:26:12 Checking 'unbound.conf' etc. for valid Syntax.....
11:26:12 Saving unbound cache to '/opt/share/unbound/configs/cache.txt' msg.cache=5266/1421 rrset.cache=9889/5100
11:26:12 Requesting unbound (S61unbound) restart.....
 Shutting down unbound...              done.
 Starting unbound...              done.
11:26:14 Checking status, please wait.....
11:26:16 Restoring unbound cache from '/opt/share/unbound/configs/cache.txt' (2023-05-06 11:26:12) msg.cache=0/1421 rrset.cache=0/5100
11:26:17 unbound OK

Yeah, I thought I saw some mention of that each time it restarted...

 

[Viktor Jaep]

@chongnt ... I'm not sure if you're using the vpnclientX-route-up/vpnclientX-route-pre-down scripts with this? But this is one thing that is still confounding me, because these scripts are seemingly ignored for some reason. This should be the easy part... I'm actually having to manually call the "unbound_DNS_via_OVPN.sh" script within VPNMON-R2 in order to get things to shut down right, and start up right. If I comment this code out in VPNMON-R2 and rely on the route-up/route-pre-down scripts, nothing happens.

Not quite sure why... here's what I have. I even added a logger statement in there to see if I could catch it doing the right thing, but nothing ever showed in my syslog... And yes, I have 5 of each, one for each of the vpnclient1/2/3...etc. And I've applied the chmod 0755 to each of them as well.

/jffs/scripts/vpnclientx-route-up

#!/bin/sh

VPN_ID=${dev:4:1}
[ -z "$VPN_ID" ] && { SCR=$(basename $0); VPN_ID=${SCR:9:1}; }    # Allow manual debugging from commandline

if [ -n "$(which unbound-control)" ] && [ -n "$(unbound-control status | grep -E "unbound.*running")" ];then
    Say "Unbound DNS requests via VPN Client $VPN_ID requested....."
    logger -t "Unbound DNS requests via VPN Client $VPN_ID requested....."
    /jffs/addons/unbound/unbound_DNS_via_OVPN.sh "$VPN_ID" start &
fi

/jffs/scripts/vpnclientx-route-pre-down

#!/bin/sh

VPN_ID=${dev:4:1}
[ -z "$VPN_ID" ] && { SCR=$(basename $0); VPN_ID=${SCR:9:1}; }    # Allow manual debugging from commandline

if [ -n "$(which unbound-control)" ] && [ -n "$(unbound-control status | grep -E "unbound.*running")" ];then
    Say "Unbound DNS requests via VPN Client $VPN_ID terminating....."
    logger -t "Unbound DNS requests via VPN Client $VPN_ID terminating....."
    /jffs/addons/unbound/unbound_DNS_via_OVPN.sh "$VPN_ID" stop
fi

Am I overlooking something simple that would prevent these scripts from automatically running based on vpn up/down events? Reading through some of the forum, some of the x3mrouting users were putting these files under their /jffs/addons/x3mrouting folder... I don't believe that's a requirement since @Martineau specifically stated these needed to be created under the /jffs/scripts folder?

 

[chongnt]

@chongnt ... I'm not sure if you're using the vpnclientX-route-up/vpnclientX-route-pre-down scripts with this? But this is one thing that is still confounding me, because these scripts are seemingly ignored for some reason. This should be the easy part... I'm actually having to manually call the "unbound_DNS_via_OVPN.sh" script within VPNMON-R2 in order to get things to shut down right, and start up right. If I comment this code out in VPNMON-R2 and rely on the route-up/route-pre-down scripts, nothing happens.

Not quite sure why... here's what I have. I even added a logger statement in there to see if I could catch it doing the right thing, but nothing ever showed in my syslog... And yes, I have 5 of each, one for each of the vpnclient1/2/3...etc. And I've applied the chmod 0755 to each of them as well.

/jffs/scripts/vpnclientx-route-up

#!/bin/sh

VPN_ID=${dev:4:1}
[ -z "$VPN_ID" ] && { SCR=$(basename $0); VPN_ID=${SCR:9:1}; }    # Allow manual debugging from commandline

if [ -n "$(which unbound-control)" ] && [ -n "$(unbound-control status | grep -E "unbound.*running")" ];then
    Say "Unbound DNS requests via VPN Client $VPN_ID requested....."
    logger -t "Unbound DNS requests via VPN Client $VPN_ID requested....."
    /jffs/addons/unbound/unbound_DNS_via_OVPN.sh "$VPN_ID" start &
fi

/jffs/scripts/vpnclientx-route-pre-down

#!/bin/sh

VPN_ID=${dev:4:1}
[ -z "$VPN_ID" ] && { SCR=$(basename $0); VPN_ID=${SCR:9:1}; }    # Allow manual debugging from commandline

if [ -n "$(which unbound-control)" ] && [ -n "$(unbound-control status | grep -E "unbound.*running")" ];then
    Say "Unbound DNS requests via VPN Client $VPN_ID terminating....."
    logger -t "Unbound DNS requests via VPN Client $VPN_ID terminating....."
    /jffs/addons/unbound/unbound_DNS_via_OVPN.sh "$VPN_ID" stop
fi

Am I overlooking something simple that would prevent these scripts from automatically running based on vpn up/down events? Reading through some of the forum, some of the x3mrouting users were putting these files under their /jffs/addons/x3mrouting folder... I don't believe that's a requirement since @Martineau specifically stated these needed to be created under the /jffs/scripts folder?

I have been using x3mrouting for sometime. I am familiar with the environment and have nothing to reference what it looks like without x3mrouiting.
Here is my understanding, any vpn event will automatically trigger /jffs/scripts/openvpn-event script to run. There are two parameters: $dev (in the form of tun11-tun15/tun21-tun22), and $script_type (either "route-up" or "route-pre-down").
What x3mrouting does is, it has a script in openvpn-event script. So any openvpn event will call the x3mrouting script. The x3mrouting script in turns look for individual scripts that has a path set to /jffs/scripts/x3mrouting, based on the two input parameters $dev & $script_type. For example, in the event of vpnc1 up, the vpnclient1_route-up script is located in this path will be called.
I don't know what it looks like without x3mrouting. Probably need to call these vpnclientX-route-up script from openvpn-event script.

Maybe can try something like this in openvpn-event script:

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start &
[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-pre-down' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &

 

[Viktor Jaep]

I have been using x3mrouting for sometime. I am familiar with the environment and have nothing to reference what it looks like without x3mrouiting.
Here is my understanding, any vpn event will automatically trigger /jffs/scripts/openvpn-event script to run. There are two parameters: $dev (in the form of tun11-tun15/tun21-tun22), and $script_type (either "route-up" or "route-pre-down").
What x3mrouting does is, it has a script in openvpn-event script. So any openvpn event will call the x3mrouting script. The x3mrouting script in turns look for individual scripts that has a path set to /jffs/scripts/x3mrouting, based on the two input parameters $dev & $script_type. For example, in the event of vpnc1 up, the vpnclient1_route-up script is located in this path will be called.
I don't know what it looks like without x3mrouting. Probably need to call these vpnclientX-route-up script from openvpn-event script.

Maybe can try something like this in openvpn-event script:

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start &
[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-pre-down' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &

I didn't even have an openvpn-event script... so I created a blank one with just a #!/bin/sh in it. I see that being called in the syslog, but no other mention of it calling the other route-up/pre-down scripts.

That sounds like a great idea... nice call! I'll let you know how things look! I'm wondering why none of this stuff was mentioned in the original @Martineau/swinson script implementation discussions?

 

[chongnt]

I didn't even have an openvpn-event script... so I created a blank one with just a #!/bin/sh in it. I see that being called in the syslog, but no other mention of it calling the other route-up/pre-down scripts.

That sounds like a great idea... nice call! I'll let you know how things look! I'm wondering why none of this stuff was mentioned in the original @Martineau/swinson script implementation discussions?

Some history when this unbound bind to vpn script started by Swinson, it is with the assumption x3mrouting is installed. Later @Martineau clarify we do not need to have x3mrouting installed to run this, which is true.

It all started from openvpn-event script. In the test script above we call the unbound script directly.

Anyway, here is x3mrouting way for reference. In openvpn-event script:

[ -s /jffs/scripts/x3mRouting/openvpn-event ] && sh /jffs/scripts/x3mRouting/openvpn-event $@

This is x3mrouting/openvpn-event script. You can see how individual route-up/route-pre-down script is getting called.

x3mRouting/openvpn-event at master · Xentrk/x3mRouting

Selectively route LAN clients, website or streaming media traffic over the WAN or OpenVPN client interfaces on Asuswrt-Merlin firmware - Xentrk/x3mRouting

github.com

 

[Viktor Jaep]

Some history when this unbound bind to vpn script started by Swinson, it is with the assumption x3mrouting is installed. Later @Martineau clarify we do not need to have x3mrouting installed to run this, which is true.

It all started from openvpn-event script. In the test script above we call the unbound script directly.

Anyway, here is x3mrouting way for reference. In openvpn-event script:

[ -s /jffs/scripts/x3mRouting/openvpn-event ] && sh /jffs/scripts/x3mRouting/openvpn-event $@

This is x3mrouting/openvpn-event script. You can see how individual route-up/route-pre-down script is getting called.

x3mRouting/openvpn-event at master · Xentrk/x3mRouting

Selectively route LAN clients, website or streaming media traffic over the WAN or OpenVPN client interfaces on Asuswrt-Merlin firmware - Xentrk/x3mRouting

github.com

You were absolutely correct, @chongnt! There's actually not even a need for any of the route-up/route-pre-down scripts as you originally suggested. I deleted them all, and ended up with your code suggesiton in the openvpn-event file:

#!/bin/sh

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start &
[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-pre-down' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &

This seems to be working PERFECTLY.

Let me go re-work my original instructional post...

 

[JGrana]

Oh yeah, the dump cache feature is available. It seems to only restore cache during router reboot.

Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) - General questions / discussion thread 2

Sorry but I cannot see how to get the Advanced menu. from the Readme on Github

www.snbforums.com

Update:
Indeed unbound restart will restore the cache by itself.

A:Option ==> rs

11:26:12 Checking 'unbound.conf' etc. for valid Syntax.....
11:26:12 Saving unbound cache to '/opt/share/unbound/configs/cache.txt' msg.cache=5266/1421 rrset.cache=9889/5100
11:26:12 Requesting unbound (S61unbound) restart.....
 Shutting down unbound...              done.
 Starting unbound...              done.
11:26:14 Checking status, please wait.....
11:26:16 Restoring unbound cache from '/opt/share/unbound/configs/cache.txt' (2023-05-06 11:26:12) msg.cache=0/1421 rrset.cache=0/5100
11:26:17 unbound OK

Yes, there was some debating about restoring the cache. The main problem was determining how old the saved cache was. On a reboot - you know it’s fairly fresh. On the other hand, if you power off the router, reconfigure something, spend a few hours futzing around - on a fresh start - the cache could be quite old.
I wrote a script to timestamp the cache file on evey ubound-control dump-cache (via cron every 10 mins).
On a services-start if the time stamped cache was older than 30 mins, no reload.
I don’t recall now how @Martineau implemented it in unbound-manager. I did this script before it was added.

 

[chongnt]

You were absolutely correct, @chongnt! There's actually not even a need for any of the route-up/route-pre-down scripts as you originally suggested. I deleted them all, and ended up with your code suggesiton in the openvpn-event file:

#!/bin/sh

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-up' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id start &
[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} &&  [ "$script_type" = 'route-pre-down' ] && /jffs/addons/unbound/unbound_DNS_via_OVPN.sh $vpn_id stop &

This seems to be working PERFECTLY.

Let me go re-work my original instructional post...

Glad that it works. But with a little caveat. If you only have one ovpn client then it works fine. If someone has more that one ovpn client, then it may not work very well. For example, the last one that come up will have unbound bind over it; or any one ovpn client went down, it may cause unbound route back on WAN etc. We don't have the flexibility of the individual route-up/route-pre-down script offers.