AdGuard Home

Netzwerkweiter Werbe-/Tracker-Blocker per DNS auf Mimir, mit dem Ziel, pro Gerät zu entscheiden, ob es gefiltert wird oder nur normalen DNS-Verkehr weitergeleitet bekommt (z. B. für Geräte, die mit gefiltertem DNS Probleme machen).

Warum AdGuard Home (statt Pi-hole oder Technitium)?

Kurzvergleich der drei Kandidaten:

	Pi-hole	AdGuard Home ✅	Technitium DNS
Per-Client-Steuerung	Gruppen (Web-UI, aber DB-lastig)	Clients-Ansicht, direkt per Klick	Advanced Blocking App, aber JSON-Konfiguration
Einrichtungsaufwand	Mittel	Niedrig	Höher
Zusatzfunktionen	DHCP-Server, große Community	DNS-over-HTTPS/TLS eingebaut, Parental Control, Schnellsperren für Dienste	Autoritativer DNS, DNSSEC, DHCP – mehr als reiner Adblocker
Roaming-Geräte	Nur mit stabiler IP zuverlässig	Etwas besser (ClientID über DoH/DoT)	Schwachpunkt laut Community

Entscheidung: AdGuard Home, weil die Pro-Client-Filterung am direktesten über die Web-Oberfläche zugänglich ist (kein DB-Zugriff wie bei Pi-hole, kein JSON-Editing wie bei Technitium).

Wichtige Einschränkung, die sich erst bei der Einrichtung zeigte: AdGuard Home hat keine echten Gruppen – anders als bei Pi-hole gibt es kein Gruppen-Objekt, dem man mehrere Clients zuordnet und dann zentral Einstellungen ändert (seit Jahren offener Feature-Request im AdGuard-Repo). Stattdessen: pro Client individuelle Einstellungen, plus ein fester Tag-Katalog (user_child, user_regular, device_*, os_* etc.), der zumindest für Custom-Filterregeln per $ctag-Modifier bulk-artig funktioniert (siehe unten).

Architektur

FritzBox (Mrs-Hudson)
  └─ Lokaler DNS-Server (Heimnetz → Netzwerk → Netzwerkeinstellungen → IPv4-Adressen)
       → zeigt auf AdGuard Home: 172.16.46.200

Synology NAS (Mimir)
  └─ Docker Container "adguardhome"
       └─ eigenes Macvlan-Netzwerk "lan_macvlan" → eigene LAN-IP 172.16.46.200
       └─ Admin-Oberfläche erreichbar über NPM (Reverse Proxy)

Wichtig: AdGuard Home läuft im Macvlan-Netzwerk (nicht Bridge!), damit es im LAN als eigenständiges Gerät mit echter IP auftritt und Clients korrekt einzeln erkennt – nur so funktioniert die Pro-Client-Filterung sauber. Details zum Macvlan-Setup (inkl. Host-Zugriffsproblem und Lösung) siehe Docker Macvlan auf der Synology.

Wichtig: FritzBox NICHT einfach als globalen Upstream-DNS auf AdGuard umstellen (Internet → Zugangsdaten → DNS-Server) – dabei würde die FritzBox als Proxy fungieren und AdGuard sähe nur noch eine einzige Quell-IP (die FritzBox), keine echten Client-IPs mehr. Stattdessen AdGuard unter Heimnetz → Netzwerk → Netzwerkeinstellungen → IPv4-Adressen → „Lokaler DNS-Server” eintragen, damit per DHCP direkt an die Clients verteilt wird.

Konfiguration

• Container-IP: 172.16.46.200 (aus reserviertem Bereich 172.16.46.200/29, siehe Docker-Macvlan)
• FritzBox „Lokaler DNS-Server”: 172.16.46.200
• Admin-Oberfläche: über NPM auf der NAS, Ziel 172.16.46.200:3000 (Setup-Assistent) bzw. :80 (nach Ersteinrichtung)
• DHCP-Pool FritzBox: eingeschränkt auf .1–.199, damit der Macvlan-Bereich .200–.207 nicht mit vergeben wird

Allgemeine Einstellungen

• Domains durch Filter/Host-Dateien sperren: an, Aktualisierungsintervall 1 Tag
• AdGuard Webservice für Internetsicherheit: an (datenschutzfreundliche Hash-Präfix-Abfrage gegen Malware/Phishing)
• Kindersicherung-Webservice + Sichere Suche: global aus, nur pro Client für die Kinder-Gruppe aktiviert (siehe unten)

Protokolle & Statistik

• Query-Log-Rotation: 7 Tage (Datenschutz – ist quasi der Browsing-Verlauf der Familie, 90 Tage Default war zu lang)
• Client-IP anonymisieren: aus (wird für Pro-Client-Debugging gebraucht)
• Statistik-Speicherintervall: 30 Tage (nur aggregierte Zahlen, kostet kaum Speicher, aber sinnvoll für Trends)

DNS-Einstellungen

• Upstream: https://dns.cloudflare.com/dns-query + https://dns.quad9.net/dns-query, Modus Lastverteilung
• Domain-spezifischer Upstream: [/fritz.box/]172.16.46.1 – leitet alle *.fritz.box-Anfragen an die FritzBox weiter, da Cloudflare/Quad9 diese lokale Domain nicht kennen. Funktioniert auch ohne DNS-Suffix-Konfigurierbarkeit in der FritzBox, da das Suffix schon clientseitig angehängt wird, bevor die Anfrage bei AdGuard ankommt
• Fallback-DNS (unverschlüsselt, Port 53): 1.1.1.1, 9.9.9.9 – Absicherung falls DoH mal nicht erreichbar ist
• Private Reverse-DNS-Resolver: aktiviert, zeigt auf FritzBox (172.16.46.1) → löst LAN-Hostnamen für die Client-Erkennung auf
• Optimistisches Caching: an
• DNSSEC: an
• Sperrmodus: Standard (Null-IP)

Verschlüsselung (DoH/DoT/DoQ am AdGuard-Server selbst)

Bewusst deaktiviert. Die Admin-Oberfläche ist bereits über NPM per HTTPS erreichbar; eine zusätzliche AdGuard-eigene TLS-Terminierung würde das nur verkomplizieren (Zertifikatspflege im Container, Risiko von Redirect-Problemen mit NPM) und bringt für rein internen LAN-Traffic kaum Sicherheitsgewinn. Kandidat für später, falls AdGuard mal für unterwegs (übers WireGuard-VPN) genutzt werden soll.

Pro-Client-Filterung / Profile

Umgesetzt über drei Profile, mangels echter Gruppen-Funktion einzeln pro Client gesetzt:

Profil	Geräte	Einstellung
Standard (keine Änderung)	NB-Dell-XP..., NB-PMHP-..., NB-SNB06..., PC-czerno..., PC-miniMe, SP-Fairlock, SP-Fernfone, TB-reMark..., TB-Wall-E (Fire HD, reines Display), VPN-NB-IPS, VPN-NB-Ri..., VPN-SP-Fa..., VPN-SP-Fe..., Mimir, Mimir-mac..., REP-james, REP-sebas..., CLK-Irne (Ulanzi/Awtrix, rein lokal per MQTT), PI-hatch (HAOS – vorerst Standard, bei Problemen mit Cloud-Integrationen später auf IoT umstellen)	„Allgemein” (erbt globale Einstellungen)
Kinder	TB-evoli (Nachfolger von TB-john, das kaputtgegangen ist)	Tag user_child, Kindersicherung-Webservice an, Sichere Suche an, Gesperrte Dienste (TikTok, Instagram, Snapchat)
IoT/ungefiltert	alle sensors-po... (Zigbee/Sonoff), shellyplugs..., shellyplus1..., ESP-flexisp..., OpenDTU-..., GS-bosch, GC-lestrade, SPORT-gar..., PRN-mrno..., PRN-SELP..., CC-chrom... (Google TV Dongle), HIFI-canto... (Soundbar, Chromecast/Tidal Connect)	„Filterung des DNS-Verkehrs deaktivieren” (Passthrough, weiter geloggt/gecacht, aber nichts geblockt)

adguard-m... ignoriert (Container-eigene MAC von AdGuard selbst, kein echtes Gerät).

Zentrale Regel für die Kinder-Gruppe ($ctag)

Einziger Weg für “gruppenweite” Custom-Regeln in AdGuard – gilt automatisch für jedes künftige Gerät mit Tag user_child, ohne pro Gerät neu geschrieben werden zu müssen:

||tiktok.com^$ctag=user_child
||instagram.com^$ctag=user_child

(unter Filter → Filterregeln)

⚠️ Wichtige Einschränkung: MAC-Identifikator funktioniert nicht ohne AdGuard-eigenes DHCP

Entdeckt 2026-07: Alle Geräte in der Client-Liste waren per MAC-Adresse identifiziert. Laut offiziellem AdGuard-Wiki funktioniert MAC-basierte Client-Zuordnung aber nur, wenn AdGuard Home selbst der DHCP-Server ist. Da bei uns die FritzBox DHCP macht, wurde keine einzige Anfrage einem MAC-identifizierten Client zugeordnet (“Anzahl der Anfragen” stand bei allen persistenten Clients auf 0, obwohl in den Laufzeit-Clients/rDNS echter Traffic sichtbar war).

Konsequenz: Die Custom-Einstellungen für Kinder- und IoT-Profil griffen dadurch nicht – die Geräte fielen mangels Zuordnung einfach auf die globalen Einstellungen zurück. Für Standard-Profil-Geräte war das folgenlos (die sollen ja ohnehin global gefiltert werden), für Kinder/IoT aber ein echtes Problem.

Fix: Identifikator bei allen Kinder- und IoT-Geräten von MAC auf IP-Adresse umstellen, kombiniert mit einer festen DHCP-Reservierung in der FritzBox („Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen”) pro Gerät, damit die IP stabil bleibt. Betrifft: TB-evoli sowie alle 12 IoT-Geräte aus der Tabelle oben. Standard-Profil-Geräte müssen nicht angefasst werden.

Status

• Docker-Macvlan-Netzwerk eingerichtet
• AdGuard-Container läuft auf 172.16.46.200
• Host-Zugriff (NAS ↔ Macvlan) via Shim gelöst
• Zugriff auf Web-GUI via NPM funktioniert
• Ersteinrichtungs-Wizard abgeschlossen
• Allgemeine Einstellungen, Protokolle, Statistik, DNS konfiguriert
• Clients in Standard/Kinder/IoT eingeteilt
• FritzBox auf AdGuard als lokalen DNS-Server umstellen (finaler Cutover)
• Feste IPs für Kinder-/IoT-Geräte in FritzBox reservieren + Identifikator in AdGuard von MAC auf IP umstellen (siehe Einschränkung oben) – in Arbeit
• Ein paar Tage Betrieb beobachten – insbesondere IoT-Geräte auf Funktionsprobleme prüfen, PI-hatch ggf. nachträglich auf IoT umstellen