VPNMON [BETA] VPNMON-R2 BETA is CLOSED. Thank you all for your help!!

[Viktor Jaep]

Remember a discussion some time ago where just binding unbound to vpn interface just didnt cut it... let me see if I can dig it up... aah here it is... you might need to backtrack alittle, but this is basically were it culminates:
https://www.snbforums.com/threads/how-to-monitor-dns-traffic-in-real-time.77151/post-747435

Thank you -- I had run across this thread, but I wasn't able to make sense of it at the time... Looking through it again, sounds like a lot of workarounds. But from my vantage point, it seems like things are working? What are your thoughts?

According to DNSMON, dns lookups are being routed out and back over the VPN:

According to dnscheck.tools, my DNS resolver is an exit in relation to my VPN exit point, and no longer showing my WAN IP as the resolver:

 

[ZebMcKayhan]

But from my vantage point, it seems like things are working? What are your thoughts?

I think I have too little experience/knowledge to dig through what is actually happening when you are binding Unbound to a vpn interface (or any other interface for that matter). My initial impression was that Unbound will only request its packets to have this source address, right (as it would normally be up to the kernal to decide)? To me it was not obvious that it would somehow bypass routing lookup through the routing rules/tables.

I still wake up sometimes during the nights with @eibgrad words echo in my head: "The binding of the network interfaces within the app itself are NOT routing decisions!" ;-)

If you say it works, it probably does. Atleast @eibgrad dns tool gives you green(-ish) results. But do you know why it works?

 

[Viktor Jaep]

I think I have too little experience/knowledge to dig through what is actually happening when you are binding Unbound to a vpn interface (or any other interface for that matter). My initial impression was that Unbound will only request its packets to have this source address, right (as it would normally be up to the kernal to decide)? To me it was not obvious that it would somehow bypass routing lookup through the routing rules/tables.

My experience is lacking as well in this area. I'm going to assume that this functionality works as advertised, because I'm not finding much reading material about the "outgoing-interface" option other than this: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html

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 interfaces. If none are given the default (all) is used. You can specify the same interfaces in interface: and outgoing-interface: lines, the interfaces are then used for both purposes. Outgoing queries are sent via a random outgoing interface to counter spoofing.

I still wake up sometimes during the nights with @eibgrad words echo in my head: "The binding of the network interfaces within the app itself are NOT routing decisions!" ;-)

Yeah I miss @eibgrad ... he was a wealth of information, and made some incredibly useful scripts.

If you say it works, it probably does. Atleast @eibgrad dns tool gives you green(-ish) results. But do you know why it works?

Based on my limited knowledge, and the output of what these tools are telling me... green is good... and believe it works. I wish I had some more know-how on digging deeper to understand why. Perhaps @Martineau or @SomeWhereOverTheRainBow might be willing to chime in to provide a bit more explanation to understand how the "outgoing-interface" works in a VPN scenario?

 

[machinist]

Yeah I miss @eibgrad ... he was a wealth of information, and made some incredibly useful scripts.

Wait, did something happen? Or did he just stop visiting, do we know?

He was an incredible help.

 

[Viktor Jaep]

Wait, did something happen? Or did he just stop visiting, do we know?

He was an incredible help.

No idea... one day @eibgrad was there, the next day he went unresponsive. Hope he's doing OK... he brought a lot of knowledge to this forum.

 

[SomeWhereOverTheRainBow]

Wait, did something happen? Or did he just stop visiting, do we know?

He was an incredible help.

It is true he is missed. @dave14305 is still around.

 

[Viktor Jaep]

Thanks to everyone for helping me take a deep dive into the inner workings of Unbound and getting this working as advertised over a VPN tunnel! I truly appreciate your knowledge and expertise on this complex subject! @dave14305 @SomeWhereOverTheRainBow @chongnt @Twiglets and others!

v2.55b4 - (Revisions as of May 6, 2023)
- MAJOR: Added major functionality to integrate more closely with Unbound! Unbound allows you to become your own DNS resolver, so you don't have to rely on other DNS providers (like from your ISP, Google, Quad9, etc.), and helps somewhat with privacy - because who knows what they log on their end, right? The downside with Unbound is that the traffic you generate for your own DNS lookups to root servers or other authoritative servers is not encrypted... which would allow your ISP (or others) to still snoop on your plaintext port 53 DNS queries. So here's the good news -- this Unbound modification (thanks to @Martineau/Swinson) forces all plaintext port 53 traffic that Unbound generates for DNS lookups over your VPN tunnel instead! This means your internet activity is even more secure from your ISP (or others) prying eyes. Please note, this is not an end-all-be-all fix to keep all DNS lookups private, but it certainly helps get you closer. This update will now require that Unbound is installed and running, and will download and/or apply other scripts to the following files:

• /jffs/scripts/nat-start
• /jffs/scripts/openvpn-event
• /jffs/scripts/post-mount
• /jffs/addons/unbound/unbound_DNS_via_OVPN.sh

-NOTE: VPNMON-R2 does not play any role in manipulating Unbound or the associated scripts in any way... it continues to function as it normally does. Except now, as openvpn events fire off as VPN tunnels are disconnected or established, this will allow these scripts to work in harmony with each other to force Unbound traffic over the VPN tunnel. Playing with these scripts and modifications isn't for the feint of heart, and may take some serious troubleshooting skills to get it configured right if something doesn't work straight out of the gate.

Beta Download:

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/VPNMON-R2/master/vpnmon-r2-2.55b4.sh" -o "/jffs/scripts/vpnmon-r2.sh" && chmod 755 "/jffs/scripts/vpnmon-r2.sh"

Significant Screenshot!
On the second config page, you'll find the ability to enable the Unbound/VPN integration functionality.

How do you know if it's working?

First... using the DNSMON tool (linked in the [OP]... if you see that the sender SRC and recipient DST match your VPN IP (in my case, 10.8.3.4), then you are sending/receiving over your active VPN connection. Remember... green is good!

Second, taking at look at the https://dnscheck.tools/ site... if you see your public VPN IP/exit and DNS resolvers are the same IP, then your VPN IP is effectively acting as your DNS resolver:

You can get even more detail running tcpdumps... but these 2 indicators above are a good sign things are working!

 

[Twiglets]

Well done, amazing work !!!
Only thing missing from your warning is the standard 'Mission Impossible' mantra !!!

I got worried for a second just reading it, waiting for the blue smoke to appear out the back of the monitor !!!

 

[Viktor Jaep]

Well done, amazing work !!!
Only thing missing from your warning is the standard 'Mission Impossible' mantra !!!

I got worried for a second just reading it, waiting for the blue smoke to appear out the back of the monitor !!!

LOL... well, I wanted to make sure people knew what they were getting into!