Unbound Understanding Unbound...

[chongnt]

OK, this is interesting. Can you explain a little how this works, and what you're seeing behavior-wise from your end? When I call the "unbound_manager vpn=3", it will change the "outgoing-interface:" dynamically to the internal VPN IP, usually in the form of an address, like: 10.0.8.3...

Are you saying you change the outgoing interface to 192.168.1.1 (or internal router br0 IP), and use this script to facilitate setting the rules for unbound to traverse over the VPN in this case?

When I first started to use unbound, I could not get "unbound_manager vpn=3" to work either. Then I found the script by @Swinson and it works right away. So yes, I leave "vpn=disable" in unbound and rely on this script to facilitate it.

Say you put the script in '/jffs/addons/unbound/unbound_DNS_via_OVPN.sh', you can manually run it. For ovpnc3, syntax to start and stop is

/jffs/addons/unbound/unbound_DNS_via_OVPN.sh 3 start
/jffs/addons/unbound/unbound_DNS_via_OVPN.sh 3 stop

.
Once stop is run, unbound traffic will go back to WAN interface. It can bind to another ovpn client by changing the vpn id.

So really weird... DNSMON is showing that queries are initiating from my tun14 interface (IP is 10.8.1.2)... yet, when I run the command:

tcpdump -i tun14 -p port 53

...it doesn't report any traffic whatsoever. And the mystery continues...

I suspect it is going through your WAN interface. Perhaps you run tcpdump on your WAN interface and see if it is there. By the way, if it is cached by unbound, there will be no outgoing query.

 

[johndoe85]

No no no no no !!!
Do not wish that on the world ..... ever.
(Remember Pandora and her problems with a certain box !!!)

I can 'hack' anything that has been well written ('standing on the shoulders of giants') but starting from scratch usually is not very good !!!

I can live with my hacks but they are not 'safe' for automagic use ..... i.e. If things fail there is usually not a 'Press this button to fix' answer !!!

I see, i request this feature nonetheless, maybe you can collaborate with some of these giants?

 

[New2This]

This Script ?

Unbound - Unbound DNS VPN Client w/policy rules

@Kingp1n I kept the added server line but re-enabled the unbound.postconf. I restarted dnsmasq the server line is in there twice now which doesn’t seem to be a problem so far and I’m currently not showing a leak. I’ll do some reboots and report back if I find anything.

www.snbforums.com

 

[Gary_Dexter]

Right... but as was stated before... if you run the command "unbound_manager vpn=4", unbound would then send all queries out over your VPN interface to prevent the ISP from snooping on that traffic, and your public VPN IP then would indicate as the DNS resolver -- I have not been able to make that happen as of yet... My question is, is this really happening, and why does the DNSMON tool show that outbound traffic looks like it's going out over the VPN, but the recipient of return traffic is coming back to the WAN interface.

I don't believe that's possible with Unbound - I don't think that is the intended functionality

 

[Twiglets]

I don't believe that's possible with Unbound - I don't think that is the intended functionality

I have been trying to solve this problem and also found that 'unbound_manager vpn=x' does not work.
i.e. Traffic does not seem to go through the tunnel, even though the vpn connection is up !!!

I have not needed to use a vpn via the router before, so this is 'New' to me !!!

BTW:
Martineau did rewrite Swinsons script to use vpn in unbound ---> Here.
[A very Useful pointer to how to get it to work ..... Once I understand what it does !!! ]
This script is also new to me, so I am doing some hacking/testing to see what I can get to work

 

[Viktor Jaep]

I don't believe that's possible with Unbound - I don't think that is the intended functionality

Well... it supposedly is? If you look under the advanced menu, there's an option to specify a vpn # command. There's a lot of documentation on getting this to work, and while it seems like it does, I'm not getting the same results... See below:

You shouldn't believe everything you read on the Internet

Once upon a time.... ha!

Of course you can use unbound with a permanently running VPN.

unbound will always use the WAN but be unencrypted (i.e. ISP snooping), and your LAN nominated Selective Routing devices can either use the VPN ISP's DNS (EXCLUSIVE) or unbound.

The only thing that is new is (optionally) unbound is also capable of sending it's requests though the VPN tunnel to prevent ISP snooping, but I doubt many have used the option within unbound_manager as it is experimental.

And I just noticed (FINALLY!) from this that the only way to get this to work is to set your "Accept DNS" in your VPN slot config to EXCLUSIVE... but then your VPN DNS servers become forwarders, and Unbound isn't really doing any root server lookups in this case, if I'm not mistaking.

 

[Viktor Jaep]

I have been trying to solve this problem and also found that 'unbound_manager vpn=x' does not work.
i.e. Traffic does not seem to go through the tunnel, even though the vpn connection is up !!!

I have not needed to use a vpn via the router before, so this is 'New' to me !!!

BTW:
Martineau did rewrite Swinsons script to use vpn in unbound ---> Here.
[A very Useful pointer to how to get it to work ..... Once I understand what it does !!! ]
This script is also new to me, so I am doing some hacking/testing to see what I can get to work

I will definitely be trying Swinson's script... thanks for the extended how-to's @chongnt! Hope to get some time to experiment SOON!

 

[SomeWhereOverTheRainBow]

So really weird... DNSMON is showing that queries are initiating from my tun14 interface (IP is 10.8.1.2)... yet, when I run the command:

tcpdump -i tun14 -p port 53

...it doesn't report any traffic whatsoever. And the mystery continues...

That might be because Unbound is randomizes its internal NAT ports before exit. So, while it appears unobservable internally, it exits out port 53 on the other end. I think alot of people misunderstand the implications and intentions of port randomization capabilities of unbound. Without internal intervention (a.k.a. adjusting settings in unbound.conf), unbound tries to make it pretty darn difficult to track and packet sniff by seperating parts of queries and randomizing exit ports. Your best place to look is the connections tracking page on your routers system log tab. Plus you need to specify you want to observe UDP port 53. I doubt unbound uses TCP only unless you tell it to. Otherwise it will typically use UDP. I am not sure tcpdump defaultly examines UDP traffic, I think you have to specify it.


Example of some unbound related traffic on my network..

@Viktor Jaep To fully appreciate unbounds capabilities, you need to observe all of your traffic in its entirety via connection tracking.

 

[Viktor Jaep]

That might be because Unbound is randomizes its internal NAT ports before exit. So, while it appears unobservable internally, it exits out port 53 on the other end. I think alot of people misunderstand the implications and intentions of port randomization capabilities of unbound. Without internal intervention (a.k.a. adjusting settings in unbound.conf), unbound tries to make it pretty darn difficult to track and packet sniff by seperating parts of queries and randomizing exit ports. Your best place to look is the connections tracking page on your routers system log tab. Plus you need to specify you want to observe UDP port 53. I doubt unbound uses TCP only unless you tell it to. Otherwise it will typically use UDP. I am not sure tcpdump defaultly examines UDP traffic, I think you have to specify it.


Example of some unbound related traffic on my network..
View attachment 49879
View attachment 49878

@Viktor Jaep To fully appreciate unbounds capabilities, you need to observe all of your traffic in its entirety via connection tracking.

I took a look at the connection tracking, and am seeing this... the 10.8.0.2 is my tun14 IP...

When I ran tcpdump:

tcpdump -i tun14 -nn -l udp port 53

... I get zero results... even tried going to some websites I've never been to thinking that they wouldn't be cached, and would force a lookup.

 

[SomeWhereOverTheRainBow]

I took a look at the connection tracking, and am seeing this... the 10.8.0.2 is my tun14 IP...

View attachment 49886

When I ran tcpdump:

tcpdump -i tun14 -nn -l udp port 53

... I get zero results... even tried going to some websites I've never been to thinking that they wouldn't be cached, and would force a lookup.

So, the silent good news is, Connection Tracking has identified my hypothesis. You would not be able to observe port 53 traffic (atleast not in the way you hoped). However, Connection Tracking shows that majority of your traffic for DNS is indeed unbound VIA your VPN.

 

[Viktor Jaep]

So, the silent good news is, Connection Tracking has identified my hypothesis. You would not be able to observe port 53 traffic (atleast not in the way you hoped). However, Connection Tracking shows that majority of your traffic for DNS is indeed unbound VIA your VPN.

So that's good news... What's your theory on this? Using Eibgrad's DNSMON tool, it shows DNS requests going out over the VPN, but it almost seems like their replies are coming back to the WAN? One would think if they go out over the VPN, they would return over the VPN?

 

[SomeWhereOverTheRainBow]

I took a look at the connection tracking, and am seeing this... the 10.8.0.2 is my tun14 IP...

View attachment 49886

When I ran tcpdump:

tcpdump -i tun14 -nn -l udp port 53

... I get zero results... even tried going to some websites I've never been to thinking that they wouldn't be cached, and would force a lookup.

Try


tcpdump -i tun14 -nn -l udp | grep :53

 

[chongnt]

I took a look at the connection tracking, and am seeing this... the 10.8.0.2 is my tun14 IP...

View attachment 49886

When I ran tcpdump:

tcpdump -i tun14 -nn -l udp port 53

... I get zero results... even tried going to some websites I've never been to thinking that they wouldn't be cached, and would force a lookup.

What’s your WAN interface? I’m on PPPoE, and in tcpdump I can capture these on ppp0 interface after I stop binding unbound to vpn.

 

[SomeWhereOverTheRainBow]

So that's good news... What's your theory on this? Using Eibgrad's DNSMON tool, it shows DNS requests going out over the VPN, but it almost seems like their replies are coming back to the WAN? One would think if they go out over the VPN, they would return over the VPN?

View attachment 49888

That is because the script is not accounting for the classify middleman address of 10.8.0.2 correctly as a vpn.

 

[Viktor Jaep]

Try


tcpdump -i tun14 -nn -l udp | grep :53

Wow, look at you, @SomeWhereOverTheRainBow!! Got some traffic! And yeah, this actually looks like results are returning back to the VPN IP! So it looks like Eibgrad's script would need some tweaking!

 

[chongnt]

So that's good news... What's your theory on this? Using Eibgrad's DNSMON tool, it shows DNS requests going out over the VPN, but it almost seems like their replies are coming back to the WAN? One would think if they go out over the VPN, they would return over the VPN?

View attachment 49888

Once bind to VPN with the script mentioned abive, DNSMON recipient dest ip is always the vpn ip in my case. I don’t think you should see your WAN IP there if it is going through VPN.

 

[SomeWhereOverTheRainBow]

Once bind to VPN with the script mentioned abive, DNSMON recipient dest ip is always the vpn ip in my case. I don’t think you should see your WAN IP there if it is going through VPN.

@chongnt I think he got the results we were expecting when he did my last tcpdump test.

 

[dave14305]

Wow, look at you, @SomeWhereOverTheRainBow!! Got some traffic! And yeah, this actually looks like results are returning back to the VPN IP! So it looks like Eibgrad's script would need some tweaking!

View attachment 49889

none of that is DNS traffic. You’re picking up the :53 seconds in the timestamp.

 

[Viktor Jaep]

Once bind to VPN with the script mentioned abive, DNSMON recipient dest ip is always the vpn ip in my case. I don’t think you should see your WAN IP there if it is going through VPN.

I'm certainly going to try the swinson/martineau script and see what my results look like there... I'm very interested in seeing it in action!

 

[Viktor Jaep]

none of that is DNS traffic. You’re picking up the :53 seconds in the timestamp.

OMG. Looks like you're right on that... DANG!