Unbound Unbound makes diversion not work?

[truglodite]

I have what is pretty much a standard AMTM install of diversion, skynet, yazfi, and some others on my ac86u (all fw and scripts up to date). It's been working fine using DOT for a while. I decided to give unbound a try today. After following the first page instructions, it seems a bunch of previously blocked ads were now making it past diversion (google etc). I double/triple checked my settings with respect to the install instructions, and played around with other settings for a couple hours trying to get it working. One weird observation, in diversion dnsmasq logs it showed several ads being blocked for the device I was testing, but the ads were in fact showing up in the browser. FWIW, I have not tried the built in unbound ad blocker, as I've been happy with diversion and according to my reading it should work fine. After giving up I uninstalled unbound and changed my configs back to what they were. It is blocking ads again, but I'd sure like to "cut out the middle man" with unbound, lol.

I was hoping if there's a general hit list of items to check when diversion fails to block after installing unbound. Guessing it's a simple config error on my part.

Any thoughts or ideas to fix this are welcome!

Tia, Kevin

 

[Ellenswamy]

Did you change anything in unbound, I just did the standard install and then installed diversion. No issues from what I can tell

 

[heysoundude]

did you re-create your DoT in Unbound? that's where it needs to live/work if you choose to use them both
diversion works/plays well with unbound (whose ad-blocking is IMHO inferior)
you can also use pixelserv-tls in diversion

 

[truglodite]

I disabled DOT before installing unbound, as my understanding is that "brings back the middleman" anyways. I just used the basic unbound manager install from AMTM, with the performance optimization and webui page, that's it. I didn't change anything with unbound afterwards. I tried reinstalling diversion, but it seems some ads are still making it through that are not there when I uninstall unbound. For example, the ad links at the top of a google search page are blocked, but the google ad frames show up when I browse for example,

My config matches all of the "prereqs" in the unbound manager install guide. I also have in webui/wan page `DNS Server = quad9` and `Forward local domain queries to upstream DNS = no`. There's no noticeable difference if I use quad9/yes.

FWIW, yes I'm using pixelserv-tls with diversion, which is one of the reasons I want to stick with diversion.

I did some more experiments and it seems diversion is working sort of. It blocks as expected on most of my devices, and dnsmasq shows blocking on diversions end, even when some of those ads get through. I did one of those adblocker sites, and it gets the same percentage score with or without unbound. So now I'm wondering what is going on... perhaps some devices are reloading locally cached ads, idk?

I'll report back if this issue persists, but I suspect it is what I thought, and just some lingering detrius on devices from testing without adblocking properly configured.

 

[Ellenswamy]

I disabled DOT before installing unbound, as my understanding is that "brings back the middleman" anyways. I just used the basic unbound manager install from AMTM, with the performance optimization and webui page, that's it. I didn't change anything with unbound afterwards. I tried reinstalling diversion, but it seems some ads are still making it through that are not there when I uninstall unbound. For example, the ad links at the top of a google search page are blocked, but the google ad frames show up when I browse for example,

My config matches all of the "prereqs" in the unbound manager install guide. I also have in webui/wan page `DNS Server = quad9` and `Forward local domain queries to upstream DNS = no`. There's no noticeable difference if I use quad9/yes.

FWIW, yes I'm using pixelserv-tls with diversion, which is one of the reasons I want to stick with diversion.

I did some more experiments and it seems diversion is working sort of. It blocks as expected on most of my devices, and dnsmasq shows blocking on diversions end, even when some of those ads get through. I did one of those adblocker sites, and it gets the same percentage score with or without unbound. So now I'm wondering what is going on... perhaps some devices are reloading locally cached ads, idk?

Are you using apple devices and seeing type=65 not being blocked?

 

[truglodite]

Yes in fact, the devices that seem to slip more ads in are ios, and yes I'm seeing the related type 65 queries in my diversion logs. I read up on this, and it seems some have configured their pihole to block all type 65. I don't want to bork anything... is there a simple 'howto' for blocking these with diversion?

[edit: Found this... not very promising: https://www.snbforums.com/threads/seeing-ads-mobile-tablets.73302/
Seems like while there is a way to block with iptables, it may also break some things. In particular, my wife and kids would freak out if snapchat or instagram stopped working at all. ]

 

[Ellenswamy]

Yes in fact, the devices that seem to slip more ads in are ios, and yes I'm seeing the related type 65 queries in my diversion logs. I read up on this, and it seems some have configured their pihole to block all type 65. I don't want to bork anything... is there a simple 'howto' for blocking these with diversion?

Yes you need to reject type =65. just log into the router with ssh and copy/paste these commands. You will stop see type=65 no longer showing in the diversion logs. When you reboot the rules will go away. So you will just have to put them back


Copy/Paste:



iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT

iptables -I FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT



Check if worked:



iptables -nvL INPUT | grep 0000410001

 

[truglodite]

Yep, just did that right before your post came in, and seems to be working so far after verifying with grep. Time will tell if it's too much for the wife/kids ios devices.

On another note, can't I just add the lines into firewall-start to survive a reboot? I have other scripts in there that use iptables to block iot devices... figured that's where it should go right?

 

[Ellenswamy]

Yep, just did that right before your post came in, and seems to be working so far after verifying with grep. Time will tell if it's too much for the wife/kids ios devices.

On another note, can't I just add the lines into firewall-start to survive a reboot? I have other scripts in there that use iptables to block iot devices... figured that's where it should go right?

I haven’t noticed any issues and my wife would have told me if she had.

i think the way it works is it will try to send dns over type=65 and if it can’t then it will just work over normal dns…


i think you can? But no clue how and don’t want to break anything.

 

[thelonelycoder]

Yes you need to reject type =65. just log into the router with ssh and copy/paste these commands. You will stop see type=65 no longer showing in the diversion logs. When you reboot the rules will go away. So you will just have to put them back


Copy/Paste:



iptables -I INPUT -p udp --dport 53 -d $(nvram get lan_ipaddr) -m string --hex-string "|0000410001|" --algo bm -j REJECT

iptables -I FORWARD -p udp --dport 53 -m string --hex-string "|0000410001|" --algo bm -j REJECT



Check if worked:



iptables -nvL INPUT | grep 0000410001

On another note, can't I just add the lines into firewall-start to survive a reboot? I have other scripts in there that use iptables to block iot devices... figured that's where it should go right?

This really should be an option in Diversion - I completely failed at following the threads about this topic. Let me put something together and push a Diversion update.

 

[Ellenswamy]

This really should be an option in Diversion - I completely failed at following the threads about this topic. Let me put something together and push a Diversion update.

You are amazing! Can’t wait for this!

 

[Treadler]

Are you using apple devices and seeing type=65 not being blocked?

Yes, & yes.

 

[^Tripper^]

This really should be an option in Diversion - I completely failed at following the threads about this topic. Let me put something together and push a Diversion update.

Yay!!! That neighbor’s cat really seems to be helping!

 

[thelonelycoder]

Yay!!! That neighbor’s cat really seems to be helping!

We‘re not on good terms, but she‘s an asset, @Viktor Jaep would agree with his grumpy one hovering over the screen.

 

[Viktor Jaep]

We‘re not on good terms, but she‘s an asset, @Viktor Jaep would agree with his grumpy one hovering over the screen.

Hahah...

 

[thelonelycoder]

Diversion 4.3.1 is out! This adds an option to add type 65 blocking as discussed in this thread.
See the release text here: https://www.snbforums.com/threads/diversion-the-router-ad-blocker-v4-2-x-and-4-3-x.74941/post-775341

 

[truglodite]

Diversion 4.3.1 is out! This adds an option to add type 65 blocking as discussed in this thread.

Thanks for adding this! I also verified the incompatible script check is working properly. It flagged me to delete my lines from firewall-start before enabling.

 

[thelonelycoder]

Thanks for adding this! I also verified the incompatible script check is working properly. It flagged me to delete my lines from firewall-start before enabling.

Good to know, I figured a few around here would add the iptables rules directly in firewall-start.
Might as well give a warning if they did.