Pi Hole Ad Blocking Gateway?
- Thread starter dlockers
- Start date
Soldato
There's a big thread in the Linux forum: https://forums.overclockers.co.uk/threads/setting-up-pi-hole.18756115/
The best way is with a Raspberry Pi really. It's super easy to set up, and a Pi uses a very low amount of power.
The best way is with a Raspberry Pi really. It's super easy to set up, and a Pi uses a very low amount of power.
Agreed. AdGuard Home + OISD.nl blocklist.
Thanks, will have a scan through. I must have forgotten the all important space/hyphen!
Interesting. That'll keep cost down - I can get a Pi3 in a case for around 36 quid if a quick Google Shopping search is to be believed.
Thanks. I had a fear from reading the thread Andy linked to about it being a nightmare longer term. The opening paragraph of OISD has cured my worry!
The huge advantage AdGuard Home has is its user friendly UI, and its superior functionality compared to pi-hole. The latter's more recent updates has closed the gap in some places, but not all. With AGH you can have all your upstream DNS resolvers (the ones your blocker uses to resolve names upstream) connected using DoH, DoT, DoQ, dnscryptv2 - or any combination thereof.
It also allows you and your users to connect to it in the same manner (provided you add an encryption certificate, eg a free LetsEncrypt one). Add in easy DHCP, client control, blocking, parental controls and client tagging and it's about perfect. Pretty graphs too.
It's very simple to set up in Docker or on a Pi, and was designed with less experienced people in mind. Here's a docker-compose for your reference. Have a play with both solutions at your convenience.
It also allows you and your users to connect to it in the same manner (provided you add an encryption certificate, eg a free LetsEncrypt one). Add in easy DHCP, client control, blocking, parental controls and client tagging and it's about perfect. Pretty graphs too.
It's very simple to set up in Docker or on a Pi, and was designed with less experienced people in mind. Here's a docker-compose for your reference. Have a play with both solutions at your convenience.
Code:
version: "2.1"
services:
adguardhome:
image: adguard/adguardhome:latest
container_name: adguardhome
network_mode: "host"
restart: unless-stopped
environment:
- PUID=1033 #change to suit your system
- PGID=100 #change to suit your system
- PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- ARCH=x86_64
- ALPINE_REL=edge
- DOCKER_REPO=multiarch/alpine
- ALPINE_MIRROR=https://uk.alpinelinux.org/alpine
- TZ=Europe/London
volumes:
- /docker/adguardhome/conf/:/opt/adguardhome/conf
- /docker/adguardhome/work:/opt/adguardhome/work
- /docker/letsencrypt/domain.com/certs:/LetsEncrypt:ro
Associate
@Rainmaker I've been a Pi-hole user for years now, but fancied a change, based on your praise of AGH. So I have installed it, but need to ask you for a bit of help with the config, if I may?
I have it installed on my Pi and working fine, using the oisd.nl blocklist as recommended. However, what I'm failing with is the encryption config. I've tried following this guide https://github.com/AdguardTeam/AdGuardHome/wiki/Encryption but am getting a certificate invalid error. I've registered a domain name, and have used CertBot to get an SSL certificate. I've then configured AGH using the given settings. However, I get this certificate invalid error. I'm wondering whether this is because I'm trying to access https://192.168.1.100 and the certificate has been issued to my domain? I don't really understand the guide to be honest :/
I have it installed on my Pi and working fine, using the oisd.nl blocklist as recommended. However, what I'm failing with is the encryption config. I've tried following this guide https://github.com/AdguardTeam/AdGuardHome/wiki/Encryption but am getting a certificate invalid error. I've registered a domain name, and have used CertBot to get an SSL certificate. I've then configured AGH using the given settings. However, I get this certificate invalid error. I'm wondering whether this is because I'm trying to access https://192.168.1.100 and the certificate has been issued to my domain? I don't really understand the guide to be honest :/
Soldato
- Joined
- 24 Sep 2015
- Posts
- 3,670
Yep. That's the reason. It is possible to issue SSL certificates to an IP address but Let's Encrypt certificates can only be issued to a fully qualified domain name.
Associate
Thanks - so is it possible to set up access to my Pi via https, or am I just making life unreasonably hard for myself in seeking to do this?
Soldato
- Joined
- 24 Sep 2015
- Posts
- 3,670
I haven't used AGH but if I were facing this problem with Pi-Hole I would setup a local DNS entry so that when I went to the FQDN that the SSL certificate is issued against I would reach the IP address of the Pi. I don't know if AGH lets you add local DNS.
TBH though, if the AGH instance is within your local network and isn't open to the internet then you could ignore the error and not worry too much about SSL. I haven't bothered setting up SSL on my Pi-Hole instances, there's little point.
TBH though, if the AGH instance is within your local network and isn't open to the internet then you could ignore the error and not worry too much about SSL. I haven't bothered setting up SSL on my Pi-Hole instances, there's little point.
Associate
To be fair, the only reason I'm contemplating it is because it's supposed to be a 'feature' of AGH. I've no actual need for it, was gonna configure it just because I could!
As the others said, you need to connect to your domain for the TLS cert to work. To be able to secure connections to an IP address (eg as with 1.1.1.1 for Cloudflare) you need to own the IP address and have control of it (leasing it from your ISP doesn't count). It helps that they also control their own CA and can sign their own certs.
As AGH (or any server) is running on your home LAN, and therefore on a private IP behind NAT, you'll need to access the domain from the public side (i.e. using the domain name and coming in through WAN from the firewall's perspective).
Depending on your router and how it's set up, you may need to manually enable NAT reflection (aka 1:1 NAT, hairpin NAT) to allow yourself to connect back in on the WAN interface to the server IP. You may also need to add a firewall rule to account for this (again, depending on firewall and how it's set up, whether it's ACL or zone based, etc).
As said above, you may also simplify this by setting a local DNS server to redirect $yourdomain.com to $server_lanIP.
I have AGH running in Docker (listening on 10.100.0.5) behind nginx, so it serves both LAN and WAN. My LAN clients connect to $domain and the router is configured to redirect to the local server IP. That way, LAN clients get bounced off the router to 10.100.0.5 (i.e. don't leave the network, one hop) and WAN clients get directed via nginx as appropriate. TLS works in both cases, as I used the domain to connect, and all my local clients (Linux, BSD, macOS, Windows 11, iOS, iPadOS etc) are all set to use DNS over HTTPS directly.
It takes a minute to set up, but once it's done and you know how, it's seconds if you ever need to do it again and it 'just works' after the inital config. The one thing I did want to pull up separately, is your certs being shown as invalid in AGH. That shouldn't happen, and is a separate matter to how clients connect...
(1) Find the cert directory (eg /etc/letsencrypt/live/domain/).
(2) In AGH, under Settings > Encryption settings (top menu), enter the domain you want to serve encrypted traffic for ($dns.yourdomain.com). Don't forget you'll need a wildcard cert from LetsEncrypt as you may wish to connect using (variously) $domain.com $dns.domain.com $doh.domain.com $dot.domain.com $quic.domain.com or whatever. You can leave the ports at default unless you have some local hackery going on (so 443/TCP for HTTPS, 853/TCP for TLS and 784/UDP for Quic). I had to set AGH to use 444/TCP for HTTPS but I don't 'really' use it. I have nginx running on the main machine and thus hogging 443/TCP (AGH is in Docker), and dns.oursecure.network hits the router > nginx > redirects to 10.100.0.5:444 for encrypted DNS. You likely can stick to 443 unless you're running a proxy or other services.
(3) Add the cert paths to the DNS > Encryption page. You *can* copy in the certs, but that's manual intervention every renewal. If you add the cert paths themselves, it'll auto-update when certbot (or Lego, or whatever) renews.
(4) If the certs error, check that AGH has permissions to access the directory. This may not be the case if they're in /etc/ (a root path). You may need to add permissions or copy them to a local (to that user) directory. Use fullchain.poem as the cert, and privkey.pem for the private key.
Any questions, hit me up. It's a nice app and works flawlessly once running.
Edit: Added pics and tidied up the explanation.
Last edited:
Associate
Thanks @Rainmaker for such a comprehensive reply, very much appreciated!
Picking up on the final point first, perhaps I've confused things with my awful terminology! I have the cert configured in AGH, the error I was referring to was an invalid cert in the address bar. So in AGH, on the Encryption Settings tab, I have statuses of Certificate chain is valid and This is a valid RSA private key. I used paths for both the certificates file and private key.
As for the rest, big learning curve for me, so I'll digest the advice and will hit you up if I need to bounce anything off you. Thanks again!
Picking up on the final point first, perhaps I've confused things with my awful terminology! I have the cert configured in AGH, the error I was referring to was an invalid cert in the address bar. So in AGH, on the Encryption Settings tab, I have statuses of Certificate chain is valid and This is a valid RSA private key. I used paths for both the certificates file and private key.
As for the rest, big learning curve for me, so I'll digest the advice and will hit you up if I need to bounce anything off you. Thanks again!
No worries, and thanks for clarifying. Yes even easier then! You just need to set up NAT reflection and connect to the local server using dns.domain.com and away you go. It should be quick and easy to set up, so if it gets mega complicated you're probably trying to do it wrong or thinking too hard.
You can always do traceroute dns.domain.com (tracert on Windows) from a local client (not the Pi hosting the server!) and see how it tries to connect. Ideally you want it to show as connecting to $publicIP and hitting it in one hop (i.e. hitting the router and being bounced back).
Soldato
Do you pay for adguard?
No, it's FOSS (Free and Open Source Software).