Block sites using Adblock

i think using a doh client that blocks ads is a good option

please be specific, what does not work?

you haven't even browsed through the adblock options, have you ?

i also tried with facebook and youtube it works but after chnging it, it remain block on clientside.
one more thing :
for above configuration it block twitter.com on router but not on client why?

yes i tried, it didn't work

so were back at Block sites using Adblock - #2 by frollic

1 Like

they already exist, and are called web browsers.

but you cant block ads in other apps

still not answering the question(s).

first time it block domains that i add in blacklist from front-end.
then remove these domain and restart adblock .
on clientside it still not access these domains and after some time it back to normal (access domain)

sorry @frollic please ask again

That's a client/browser issue. ARP & browser caching.

5 Likes

The rule in your screenshot above is invalid BTW.

The Zone's LAN Input Accept Rule should allow DNS traffic.

What's wrong with that? It redirects all DNS queries from the specified zone (lan) to the local DNS resolver and applies to UDP and TCP protocol. In uci it looks like this:

config redirect 'adblock_lan53'
	option name 'Adblock DNS (lan, 53)'
	option src 'lan'
	option proto 'tcp udp'
	option src_dport '53'
	option dest_port '53'
	option target 'DNAT'
	option family 'any'
1 Like

As noted:

Perhaps it does work, but the traffic is input - no need to redirect. I was just noting that a normal Input traffic rule would also work.

but this rule is not for that purpose, ie. access DNS server, but to force dns traffic to router.
i.e. prevent work around router's dns server by specifying a different dns server on client.

1 Like

Nope, I guess that's only a visual bug in LuCI. Therefore I've already listed the correspondent uci entries with the 'any' option.

3 Likes

Correct, jow merged a fix to LuCI fw4 a couple weeks ago that lets you select address family for both port forwards and NAT rules, which includes correcting the display of those settings.

1 Like

The fix ...

... seems to be incomplete, e.g. current master:

I've quickly added some (missing?) logic in forward.js (line 41 + 42):

ipv4: ((!family && dip.length > 0 && dip.indexOf(':') == -1) || (!family && dip.length == 0) || family == 'ipv4'),
ipv6: ((!family && dip.length > 0 && dip.indexOf(':') != -1) || (!family && dip.length == 0) || family == 'ipv6'),

... and now it works like expected ... :wink:

edit: I've opened a PR (https://github.com/openwrt/luci/pull/6331), let's see if it is accepted.

7 Likes