Unbound unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server)

[L&LD]

Commercial/public VPN's have never been useful for privacy. Contrary to marketing schemes stating otherwise.

 

[Chris0815]

I've uploaded v3.05

FIX:      'vpn x' doesn't always apply new VPN gateway IP, nor does it validate VPN Client instance/Gateway IP

Started my VPN-Client several times to get new IP. Now the new IP was integrated each time into the unbound.config without any problems! Thank you for updating!

 

[Martineau]

Started my VPN-Client several times to get new IP. Now the new IP was integrated each time into the unbound.config without any problems! Thank you for updating!

Sometimes I strike lucky!

 

[ugandy]

Commercial/public VPN's have never been useful for privacy. Contrary to marketing schemes stating otherwise.

i assume that unless one has access to the vpn provider's logs, the privacy is safe, no? or at least very hard to figure who is who on the vpn tunnel exit data (among all the data going through the exit)?

 

[Kingp1n]

Started my VPN-Client several times to get new IP. Now the new IP was integrated each time into the unbound.config without any problems! Thank you for updating!

All is working without issues with latest update. No more errors when typing "vpn 1" in advanced mode and everything installed without issues. We'll continue to monitor this neat VPN feature with unbound!!!

One last question (I hope), I currently have IPV6 disabled; will the experimental feature work w/IPV6 once enabled as far as sending requests thru VPN tunnel to prevent snooping?

 

[SuperDuke]

One question that currently occurred to my usage:
I used the command "vpn 1" to use DNS over VPN. Installation worked fine.

[✔] unbound requests via VPN Client  (10.8.0.8) tunnel ENABLED

10.8.0.8 was also integrated into the config and everything went fine.
Today the IP of my VPN was changed. Current IP is 10.8.3.5. So no DNS resolution possible anymore. So everything working correct.

So I deactivated DNS over VPN by the command "vpn disable". Also working, I could resolve DNS again.
Then I typed the command "vpn 1" again in order to use DNS over VPN with the new IP (10.8.3.5).
But outbound seems to use the old IP for the outgoing interface:

[✔] unbound requests via VPN Client  (10.8.0.8) tunnel ENABLED

Would it be possible that the new IP is integrated in the config? Or am I doing something wrong?

Forgive my ignorance (again!), but is this feature actually using the VPN services DNS servers or is this feature actually a true tunnel through VPN end-to-end (with one end being unbound requests)?

If the former, I understand.

If the latter, then how does one overcome the login credentials when trying to access actual VPN servers themselves?

Thanks as always....

 

[L&LD]

i assume that unless one has access to the vpn provider's logs, the privacy is safe, no? or at least very hard to figure who is who on the vpn tunnel exit data (among all the data going through the exit)?

I would say 'no'. When you consider that governments and other 'super bodies' want/need access to this data, it doesn't matter what the VPN provider promises, the powers that be would already have the info they require.

Don't forget that they don't need to build a case on what is happening 'now', they can build a case for a specific user over time and they will be more and more accurate as time (and data) accrues.

I believe that being on a VPN, you're already giving a flag that they should watch you.

With unbound going directly to the authoritative DNS servers (usually once, until the cache expires), there is far less chance of being singled out, IMO.

 

[ugandy]

I would say 'no'. When you consider that governments and other 'super bodies' want/need access to this data, it doesn't matter what the VPN provider promises, the powers that be would already have the info they require.

Don't forget that they don't need to build a case on what is happening 'now', they can build a case for a specific user over time and they will be more and more accurate as time (and data) accrues.

I believe that being on a VPN, you're already giving a flag that they should watch you.

With unbound going directly to the authoritative DNS servers (usually once, until the cache expires), there is far less chance of being singled out, IMO.

true.

but to keep comcast out of my dns queries, i think unbound+vpn is sufficient

 

[L&LD]

Depends if the VPN you're using isn't using Comcast as an exit node.

Or, if Comcast is even the one you should be worrying about at all.

 

[ugandy]

@Martineau i've noticed that when "unbound_manager vpn=2" is invoked from the route-up trigger, it has no effect.
but it works great when invoked from shell prompt.

the call to "unbound_manager vpn=disable" works great when invoked from the route-pre-down trigger.

maybe i need to increase my route_delay parameter? could it be that the unbound vp2=2 is being called too soon?

thanks
hugo

 

[figorr]

After the update my Unbound is not creating the stats automatically every hour.

Now the only way to show updated stats on the Gui is to manually push the button or run it through the script.

 

[Chris0815]

@Martineau i've noticed that when "unbound_manager vpn=2" is invoked from the route-up trigger, it has no effect.
but it works great when invoked from shell prompt.

the call to "unbound_manager vpn=disable" works great when invoked from the route-pre-down trigger.

maybe i need to increase my route_delay parameter? could it be that the unbound vp2=2 is being called too soon?

thanks
hugo

Same behavior at my end. I finally configured yesterday like proposed in post #1504. If VPN Clinet goes down, outgoing interface within outbound is triggered correctly, but when VPN Client goes up, triggering unbound "vpn 1" does not work. I still use vpn 1, not vpn 2 like mentioned by ugandy.

 

[Chris0815]

Forgive my ignorance (again!), but is this feature actually using the VPN services DNS servers or is this feature actually a true tunnel through VPN end-to-end (with one end being unbound requests)?

If the former, I understand.

If the latter, then how does one overcome the login credentials when trying to access actual VPN servers themselves?

Thanks as always....

My understanding is that unbound DNS over VPN does NOT use the DNS of the VPN provider. But it uses a configured VPN Client to communicate with the severs for performing recursive DNS within unbound. So ISP in not able to sniff this DNS traffic - lets say not that easy...
I like the advantage of this setup to use also DNS-chache, the DNS-firewall and the DNS-adblock installed within my router - and not to be dependent on the DNS provided by the VPN provider. But for sure you need login credentials to have a running VPN Client...
I now that in this way I am leaking my WAN IP at DNS-leak test, but I my understanding is that I leak this information to single web-pages, not to one single ISP who knows already a lot of my personal data... But it depends on the aim of usage...

 

[Martineau]

@Martineau i've noticed that when "unbound_manager vpn=2" is invoked from the route-up trigger, it has no effect.
but it works great when invoked from shell prompt.

the call to "unbound_manager vpn=disable" works great when invoked from the route-pre-down trigger.

maybe i need to increase my route_delay parameter? could it be that the unbound vp2=2 is being called too soon?

thanks
hugo

Doh...you think I'd remember from my VPN_Failover.sh script.

You are correct, 'unbound_manager' is called too early.

I've pushed a Hotfix v3.05 Github md5=d3c0245a78f789d14f80de41f36d1ced

When calling 'unbound_manager' from 'vpnclientX-route-up', the VPN connection has not yet been physically established (no VPN Client Gateway IP) so hopefully the script is currently putting the following in Syslog?

(unbound_manager.sh): nnnnn Starting Script Execution (vpn=2)
(unbound_manager.sh): nnnnn ***ERROR VPN Client '2' is NOT Connected?

So you need to run 'unbound_manager' asynchronously from

/jffs/scripts/vpnclientX-up

/jffs/addons/unbound/unbound_manager.sh   vpn=X   delay=1   &

i.e. one second after 'vpnclientX-up' has terminated.

NOTE: I could always wait one second, but just in case establishing the physical VPN Server connection takes longer, you can increase the delay up to a maximum 99 seconds.

 

[Martineau]

Same behavior at my end. I finally configured yesterday like proposed in post #1504.

EDIT: Updated post #1504

If VPN Clinet goes down, outgoing interface within outbound is triggered correctly, but when VPN Client goes up, triggering unbound "vpn 1" does not work. I still use vpn 1, not vpn 2 like mentioned by ugandy.

see post #1574

 

[Chris0815]

So you need to run 'unbound_manager' asynchronously from

/jffs/scripts/vpnclientX-up

/jffs/addons/unbound/unbound_manager.sh vpn=X delay=1 &

i.e. one second after 'vpnclientX-up' has terminated.

Tested - and: BAAAAM - its working perfectly!
thank you Martineau! Again! Directly solved!

 

[Martineau]

Tested - and: BAAAAM - its working perfectly!
thank you Martineau! Again! Directly solved!

@Chris0815 Sorry for the inconvenience ...hopefully it's an improvement on having to manually update the VPN Gateway IP - perhaps it's now ready for 'Easy' menu mode users?

P.S. Hope you have considered/implemented the (just-in-case) fall-back/failsafe during an unsolicited reboot!

 

[Deleted member 62525]

I would say 'no'. When you consider that governments and other 'super bodies' want/need access to this data, it doesn't matter what the VPN provider promises, the powers that be would already have the info they require.

Don't forget that they don't need to build a case on what is happening 'now', they can build a case for a specific user over time and they will be more and more accurate as time (and data) accrues.

I believe that being on a VPN, you're already giving a flag that they should watch you.

With unbound going directly to the authoritative DNS servers (usually once, until the cache expires), there is far less chance of being singled out, IMO.

Could not agree more. Since we are on this, I don't get the point of configuring Unbound over VPN client. This will not get you any more security than adding DHCP-OPTION DNS 127.0.0.1 in your openvpn config since this will force the vpn client to use Unbound.

 

[juched]

After the update my Unbound is not creating the stats automatically every hour.

Now the only way to show updated stats on the Gui is to manually push the button or run it through the script.

Can you show the output of the command

cru l

 

[Chris0815]

@Chris0815 Sorry for the inconvenience ...hopefully it's an improvement on having to manually update the VPN Gateway IP - perhaps it's now ready for 'Easy' menu mode users?

From my point of view DNS over VPN is perfectly working now. I get a new IP from my VPN provider not only once a week. So combined with the openvpn-event-trigger it works perfectly!
Would it make sense that the openvpn-event-trigger is also integrated automatically in your manager? Just an idea? Otherwise it could happen that DNS will not work (if VPN goes down or VPN Client gets a new IP) if not adapted the trigger script manually. I don't know if somebody who uses the Easy-menu is also able to implement the things needed for openvpn-trigger-commands...
I personally got used to it, but only after reading a lot here in the forum how to implement...

P.S. Hope you have considered/implemented the (just-in-case) fall-back/failsafe during an unsolicited reboot!

May be this is the next little Challenge for me...