Adblock vs Adguard Home

How about DHCP? To my knowledge dnsmasq provides both name resolution and IP address serving (as well as static leases). Do you mean I would have to have dnsmasq for DHCP, adguard for name resolution and Adblock to get rid of unwanted ads?

Is there a particular order in which I would go about installing and configuring the 3 services?
I mean, do I need to install one package first, then set it up, reboot then go about setting the others, in a similar fashion, or should I simply download the two optional packages, then simply configure everything from the Luci Interface in a single shot?

1 Like

Yes, I first thought about it, but its more than a thousand lines long and I got scared of ruining the whole setup by screwing the script up.

1 Like

Install, adblock and it's lists.

Have your DNS server use the adguard DNSes as its source of DNS names.

DHCP should obviously point towards your DNS running on the router.

Don't forget to block or catch and redirect outgoing DNS calls trying to leave your LAN.

1 Like

There is no luci add-on for Adguard, seems to be running its own web page from quick overview of install doc.

Thanks for all your previous input. I have installed both Adblock and AdGuardHome. I've setup AdGuardHome from the setup page at [myrouter-ip-address]:3000 to provide DNS name resolution from port 5353. But I'm not sure how I make the router itself use this instance as it's DNS server for name resolution.

I've tried all Diagnostics utilities from Luci Network/Diagnostics, and found out that name resolution is still working, but seem to be getting data from the original dnsmasq that apparently is still operational from port 53.

I'm hesitant to change the port from Luci Network/DHCP and DNS, as per image below. Is this the correct place to make the necessary change? Looks to me that this would instead change the original dnsmasq name resolution conflicting with the port I've mentioned above for AdGuardHome...

EDIT: I don't know if I got it right, but I added list server '192.168.1.1#5353' to the dnsmasq section of /etc/config/dhcp and now it seems that it's working like this:

  • system dns server: original dnsmasq existing from default OpenWrt installation, on port 53.
  • dnsmasq then forwards queries to AdGuardHome's dns server on the same machine, but on port 5353.

I also added the following to /etc/firewall.user:

nat -A PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to 192.168.1.1:5353
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 53 -j DNAT --to 192.168.1.1:5353

Questions:
a) Am I on the right track, or should I change anything?
b) How about DHCP? Is it still being taken care of by the original dnsmasq instance?

Best regards

Yes, I know. I've set mine to run from port 8080. Tks for your help, though.

Sounds to me you're set it up right, good work.

DNS used by router, and DNS advertised by it to the clients, are two different things.

I personally, would have left the default DNS for the router, but let the clients use the adblock+adguard combo.

Not a user of adguard myself, but why not simply use the public adguard DNSes listed, as your DNS provider?
https://kb.adguard.com/en/general/dns-providers#adguard-dns

1 Like

[HowTo] Running Adguard Home on OpenWrt - Community Builds, Projects & Packages - OpenWrt Forum

AdGuard is in the opkg repositary however it is v104. Adguard via install script is on 107. There are some substantial issues solved between them and some outstanding issues.

TLDR? (too long didnt read)
AdGuard is a nice blocker much like Adblock and also Pihole. You can pretty much get similar blocking from all 3 by using good lists.
(:edit: Beware when using lots of lists on small memory routers. DNS services WILL crash when they run out of mem and get process reaped)

Adguard however if you configure it to use their DNS service can offer some upstream blocking as well.

Adblock is fairly simple with stats.
Pihole and AdGuard give you more stats.

AdGuard /can/ do dhcp. however at present, I wouldnt use it that way. There are some fairly substantial deficiencies with their implementation and OpenWRT has improved DHCP v6 handling. Adguard has not. Best of both worlds would be for AdGuard to pull some of those fixes into their tree. They freely admit their DHCP needs work and merging but its "on the list" to do.

:edit: This is an important point. AdGuard has a significant issue in that uses the tmp folder. This is WIPED when you reboot your router. As such there needs to be a patch for Adguard or a better configureation setup (the DHCP leases and reservations are held there and you will have to redo reservations everytime you reboot the router. Unless you use a usb stick and a tmp folder redirect. This may not be possible on all routers)
:edit2: Ability to edit "DHCP static leases" entry after its saved · Issue #1700 · AdguardTeam/AdGuardHome (github.com) < the dhcp lease issue.

4 Likes

This is how i configured AdGuard using RC3. Just be aware that the opkg version is 104. Latest Edge version of AdGuard is 107. So i'd say use their script to install off their site instead of installing the opkg version.

Making it so you block with AdGuard and use dnsmasq/ohdhcp for the backend.

However. if u just suppliment the lists that adblock has with extra lists you should be able to do the same.

What differs however is that by using adguard you can do DoH and secure dns all in one package and also set multiple upstreams fairly easily.

1 Like

From my adguardhome.yaml file here is my filters section:

filters:
- enabled: true
  url: https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt
  name: AdGuard DNS filter
  id: 1
- enabled: false
  url: https://adaway.org/hosts.txt
  name: AdAway Default Blocklist
  id: 2
- enabled: true
  url: https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV-AGH.txt
  name: Perflyst and Dandelion Sprout's Smart-TV Blocklist
  id: 1625359387
- enabled: true
  url: https://raw.githubusercontent.com/durablenapkin/scamblocklist/master/adguard.txt
  name: Scam Blocklist by DurableNapkin
  id: 1625359388
- enabled: true
  url: https://raw.githubusercontent.com/mitchellkrogza/The-Big-List-of-Hacked-Malware-Web-Sites/master/hacked-domains.list
  name: The Big List of Hacked Malware Web Sites
  id: 1625359389
- enabled: true
  url: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
  name: https://github.com/StevenBlack/hosts
  id: 1625359390
- enabled: true
  url: https://osint.digitalside.it/Threat-Intel/lists/latestdomains.txt
  name: https://firebog.net/  - OSINT.digitalside.it
  id: 1625359391
- enabled: true
  url: https://v.firebog.net/hosts/Easyprivacy.txt
  name: https://firebog.net/  - EasyPrivacy
  id: 1625359393
whitelist_filters:
- enabled: true
  url: https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt
  name: https://github.com/anudeepND/whitelist
  id: 1625359392

You can add these manually via the filters tab.
Add the whitelist via the dns allowed list.

Gives about 130k of blocks. Thats fairly close to my 145k i used to have via my pihole. However there is likely some overlap. I do miss PiHoles list merging as it was less critical if some lists duplicated each other. I did find this for adguard but have yet to try it. AdguardTeam/HostlistCompiler: A simple tool that compiles hosts blocklists from multiple sources (github.com)

1 Like

Thanks for your posts.

Do you think I could go out and simply install the script version (107) on top of the packaged version (104)? Or, should I first remove the packaged version?

Use adblock or AdGuard. Both can do the same.

I tried installing over top and ran into issues. Probably wiser to remove the packaged version and reboot. Then install the new script version. They install to different locations anyway. I will be rebuilding my router to try again as I'm fairly sure the weird issues i'm having are due to the mixed issues.

:edit: i'm using a BT Hub 5 with only 128mb of ram. The new beta stats / dashboard page on port 3001 is giving me 404 errors or not loading pages. but the old dashboard on port 8080 (where i installed it) is working ok. I'm unsure if this is because of mixed config pages or something else. Thus why i'm doing clean install and trying the edge 107 version from clean install and then examining the yaml file it will create. They appear to be "agile" in development. aka, patch and ask ppl to try it out. Thus why the edge builds are most likely to be bug fixed. I have found out that the DHCP lease issue is due to be patched in 108. I'm interested to see how they will fix it and if it will work with OpenWRT nicely or if i will have to request fixes.

1 Like

Yes, I noticed this after I posted my previous message.

I just installed the last beta and was able to configure from port 3000, not 3001. From there I chose for it to run on port 8080.

they appear to have a beta dashboard that is experimental. It installed on port 3001 for me. I've just reinstalled my router and was checking the install for the regular release which is currently v0.106.3.

This version doesnt have that dashboard but i'm in the middle of bugreporting an issue with the install script and i'll have a go with the latest release in a bit.

I did notice this however. AdGuard Home will be installed into /opt/AdGuardHome
This resolves some of the issues with the /tmp being wiped on reboot but may end up with out of space issues as the queries log fills up. I think just having some sensible values for logging should deal with that for OpenWRT users.

How bizarre... I have not installed the latest beta. I have just verified from the 8080 dashboard and the script installed the last released version, not the beta as I thought before. Sorry for my previous misleading post. I've tried to edit my previous message to change from beta to released on last paragraph, but it seems I cannot anymore.

If you have a peek in the adguardhome.yaml file that is in /opt/AdguardHome you should see this

bind_host: 192.168.1.1
bind_port: 8080
beta_bind_port: 3001 

The beta port is the "new" dashboard. It was also the one i was having issues with when i last tested but i was testing with an over the top install and i didn't know if that was the reason. Now i have a clean install and can poke and play and break more things :slight_smile:

I do have a concern with how it installs however. Its causing me some thought as it really requires a re-write or a better way of doing the interface selection.

Right now if you tell it "All Interfaces" it binds to 0.0.0.0 however this then means it will serve DNS on your PUBLIC interface (which really isn't advisable).

it would be better to maybe select which interfaces rather than do an ALL or just one.
Mostly because you want DNS on loopback (127.0.0.1), your ip4 lan (192.168.1.1) and your ip6 lan (::1) but you don't want it on the public interfaces.

Also there is NO Way at present to edit these values once it has done its initial setup other than to manually edit the yaml file which isn't ideal for newer users. Maybe some sort of initial config page needs adding or the install process adjusting. I'm going to have a think about things and see if i can write up something to report as an issue for their team.

So. The beta dashboard is nice looking however. Still broken. It will give you the main dashboard pages instead the proper subpages. Opening the sublinks gets a 404.

Also given my router is a bt hub 5 and only has 128mb of memory...

I feel the stats pic from the bottom of the beta page may be inaccurate...

1 Like

Mine shows 0 for beta_bind_port. I suppose it's because its release, not beta.

Yes, there should be a way of maybe re-run the initial setup to change settings in case the user changes his/hers mind after initial setup. Have you tried renaming the yaml file to something else and restarting the service to see if it enables the setup page again?
At least this should allow users to compare yaml files side to side.

i wouldnt say it beta. More like alpha. I am going to have a look and see if they have any notes or explainations about the beta pages and if there are issues filed on them.

regarding the yaml file. i just edit it to change values. I acutally install it on port 5353 then swap openwrts dnsmasq dns port from 53 to 5353 and swap Adguards from 5353 to 53. This way instead of it being an upstream feed for openwrt its the acutal source dns and thus can give me proper statistics instead of the 127 loopback that openwrt uses.

so like this.

Clients > Openwrt > Adguard via 127.0.0.1 upstream feed > DNS

Port change and it becomes

Clients > Adguard > DNS
with OpenWRT running in background on port 5353 as a "backup" dns (i have it set to use googles dns) My Adguard uses cloudflare. Just makes double checking which dns is in use easy. Just do a dns leak test and see which is reported.