That's a good suggestion, but unfortunately UDP is blocked on my work environment, so a direct WireGuard connection isn't possible. Tailscale's DERP relay over TCP 443 is the only option that works in my environment.
VLESS & XTLS-Reality
In general, search and consider the options.
1 Like
Thanks for the suggestions, but I'd prefer not to get into VPS-based solutions for now. After some investigation, I've figured out that the main issue is with adblock-fast since it's DNS-based and doesn't work well over the Tailscale relay. Everything else including PBR policies are working fine. I'm planning to try adblock-lean or a simple adblock solution on my subnet router instead. If that works, I'll be good to go!
The most important thing in your approach is not to offend the author! He might get really upset, and everything could break because of that. But the fact that you're open to trying an alternative is both great and a bit bittersweet ))).
Good luck!
1 Like
I have so much respect for author, and I never want to undermine that. The alternative idea is just a little 'what-if' experiment on my end—nothing is set in stone!
Well, I kind of argued with the author about his other plugin, and now I have no say. Because everything's great, and I'm the one making up the bugs. And if that's true, then not only my opinion, but even my existence as a human being contradicts the author's worldview. Because anyone who's against it isn't human and doesn't even have a say.
1 Like
Please elaborate if you're trying to cover your WR3000S clients by the upstream router's pbr/doh/adblock or if the services running on WR3000S (pbr, doh, adblock) are failing because of your tailnet uplink?
Either way in addition to relevant logs/captures from WR3000S, you'll need to post/capture your headscale/tailnet DNS settings.
I'm trying to cover WR3000S clients by the upstream router's (RT3200) pbr/doh/adblock services. The WR3000S is configured as a Tailscale exit node client, using RT3200 as the exit node.
What works:
PBR policies are working correctly
DoH via https-dns-proxy on RT3200 is working
What doesn't work:
Adblock-fast on RT3200 is not blocking ads for WR3000S clients — maybe this is because adblock-fast is DNS-based and the DNS queries from WR3000S clients don't reach RT3200's dnsmasq in a way that properly triggers the ad blocking
Current Tailnet DNS settings:
Global nameserver: 100.102.59.65 (RT3200 Tailscale IP) with 'Use with exit node' enabled
Override DNS servers: disabled
MagicDNS: enabled
The WR3000S is connected to RT3200 via Tailscale relay (DERP - 'par' Paris) since UDP is blocked on the office network. I believe the relay is causing the DNS-based adblock to not function properly for WR3000S clients.
update
Resolved!
I have adblock-fast configured on a Cudy WR3000S running as a subnet router (connected to a main RT3200 exit node)
Root cause was two issues:
- DNS resolving
downloads.openwrt.orgto IPv6 (unreachable) — fixed with static IPv4 entry in/etc/hosts - Broken
curlandzliblibraries
adblock-fast now running perfectly
Thanks to the author for this brilliant lightweight solution
Submitted an 1.2.4-r4 version extension to the Chrome Web Store, it has the following fixes:
- proper detection of installed extension from luci app (no more nag to install extension if it's actually installed)
- better icons
Once thru the review step (should be days, not hours tho), the new extension will land in your browsers automatically.
2 Likes
I'm new to this OpenWRT, I manage two flash 2 different routers. I decided to install adblock fast, did the basic setup and works great. I manage to get it working on Both Wired and Wireless.
After some minutes of usage on Wireless it stopped on both devices(No ad blocking on Wireless only).
Here's the setup.
I'm using both my C6U and R3A as "Wireless Extenders"
The Current interfaces are
wwan>Internet from ISP router
lan> no actions performed aside from an static IP address
bridge> Relay Bridge
Adblock Fast settings
Force Router DNS
DNS Service > dnsmasq servers file
Adblocking for all instances - yes
Force RouterDNS to all local - yes
If anyone can direct me on what I did wrong I will really appreciate. Weird thing is that it worked on wireless for 5 minutes.
Thanks!
Based on your description, my guess would be that your wireless device briefly hopped/roamed onto your ISP router's wifi and cached blocked domains resolved IPs.
Can you try rebooting your wireless devices and making sure they don't connect to your ISP router anymore after the reboot?
Still not working. Irebooted all three devices—the main router and the two extenders as well as my personal phone.
I also confirmed that I'm not using a Private DNS on my phone. Right now, adblock only works over a wired LAN connection because I have a computer plugged in.
Is it possible that the main router is somehow overwriting the ForceRouterDNS setting from the extenders?
This is what I followed to setup the extenders Wi-Fi Extender/Repeater with relayd - Openwrt
It might be beneficial to post exact network/firewall and wifi configs redacting any passwords.
I'm puzzled as to why ad-blocking is working on wired clients, but not wireless, nor why it woked for 5 minutes but no more.
Hi @stangri,
I have a suggestion regarding the default when adblock-fast is enabled for all instances (config.dnsmasq_instance='*').
Instead of adding servers-file=/var/run/adblock-fast/dnsmasq.servers to every instance, add it only to the first instance. Then, for the other instances, just set noresolv=1 and point them at the first one with server=<first instance IP addr>.
This would reduce RAM usage a lot on multi-instance setups. The tradeoff is that the other instances would then depend on the first instance being up for filtering, but for most setups that should be an acceptable compromise.
1 Like
Thanks for the thoughtful suggestion — the motivation is legit. In the current dnsmasq.servers mode I set serversfile= on every targeted instance, and each dnsmasq process loads the whole list into its own memory, so on multi-instance setups you really do pay the blocklist's RAM cost N times.
That said, I don't think this should be the default for dnsmasq_instance='*', because noresolv=1 + server= isn't really a memory optimization — it re-points each other instance's entire upstream resolution path at the first instance. A few concerns with making that automatic:
- It collapses per-instance config. People usually run multiple dnsmasq instances precisely because they want them to differ — different upstreams per VLAN, split-DNS, separate local domains/DHCP. Funneling everyone upstream through instance 1 silently overrides that.
- It's a SPOF for all resolution, not just filtering. With noresolv=1, when instance 1 restarts/reloads (which adblock-fast does routinely on updates), the other instances lose all upstream resolution, not just ad blocking.
- "First instance" isn't well-defined. Instances bind to specific interfaces/addresses and sometimes non-53 ports; there's no guarantee instance 2 (e.g. a guest-VLAN resolver) even has a route to instance 1's listen address, and UCI order isn't a stable/meaningful selector.
- Double-forwarding through another dnsmasq also shifts cache/DNSSEC/ECS behavior in ways users didn't opt into.
The filtering itself would still work for forwarded queries (instance 1's server=/blocked/ entries apply), so the idea is technically sound — it's the blast radius that makes me wary of doing it silently.
What I might consider in the future: offering this as an explicit opt-in rather than changing the wildcard default — e.g. an option where you designate a "primary" instance and the others become dependent forwarders, so users who run identical instances purely to serve multiple interfaces get the RAM savings while knowingly accepting the dependency, and users with genuinely independent instances don't get their DNS rewired underneath them.
Would that work for your setup?
2 Likes