Unbound Unbound makes diversion not work?

truglodite

Regular Contributor
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

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

heysoundude

Part of the Furniture
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

Regular Contributor
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.
 
Last edited:

Ellenswamy

Regular Contributor
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

Regular Contributor
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. ]
 
Last edited:

Ellenswamy

Regular Contributor
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

Regular Contributor
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

Regular Contributor
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

Part of the Furniture
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.
 

thelonelycoder

Part of the Furniture

Viktor Jaep

Very Senior Member

thelonelycoder

Part of the Furniture

truglodite

Regular Contributor
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

Part of the Furniture
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.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top