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!I've uploaded v3.05
Code:FIX: 'vpn x' doesn't always apply new VPN gateway IP, nor does it validate VPN Client instance/Gateway IP
Sometimes I strike lucky!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!
Commercial/public VPN's have never been useful for privacy. Contrary to marketing schemes stating otherwise.
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!!!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!
One question that currently occurred to my usage:
I used the command "vpn 1" to use DNS over VPN. Installation worked fine.
10.8.0.8 was also integrated into the config and everything went fine.Code:[✔] unbound requests via VPN Client (10.8.0.8) tunnel ENABLED
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:
Would it be possible that the new IP is integrated in the config? Or am I doing something wrong?Code:[✔] unbound requests via VPN Client (10.8.0.8) tunnel ENABLED
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.
@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
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....
Doh...you think I'd remember from my VPN_Failover.sh script.@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
(unbound_manager.sh): nnnnn Starting Script Execution (vpn=2)
(unbound_manager.sh): nnnnn ***ERROR VPN Client '2' is NOT Connected?
/jffs/addons/unbound/unbound_manager.sh vpn=X delay=1 &
EDIT: Updated post #1504Same behavior at my end. I finally configured yesterday like proposed in post #1504.
see post #1574If 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.
So you need to run 'unbound_manager' asynchronously from
/jffs/scripts/vpnclientX-up
i.e. one second after 'vpnclientX-up' has terminated.Code:/jffs/addons/unbound/unbound_manager.sh vpn=X delay=1 &
@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?Tested - and: BAAAAM - its working perfectly!
thank you Martineau! Again! Directly solved!
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.
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.
cru l
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!@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?
May be this is the next little Challenge for me...P.S. Hope you have considered/implemented the (just-in-case) fall-back/failsafe during an unsolicited reboot!
Welcome To SNBForums
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!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!