DNS Timeout mit FritzBox und PiHole Docker

Hallo,

ich betreibe seit einiger Zeit erfolgreich PiHole auf einem Fedora Server in meinem Heimnetz. PiHole ist dabei direkt auf der Hardware installiert. Die Konfiguration ist so, dass in der FritzBox-Konfiguration der PiHole-Server als einziger Upstream-DNS angegeben ist. Die Clients in meinem Netzwerk bekommen aber weiterhin per DHCP die FritzBox als DNS-Server. Das ist so gewollt und funktioniert auch prima.

Allerdings würde ich gerne auf die Docker-Version von PiHole umsteigen. Diese bekomme ich in dieser Umgebung nicht zum Laufen: Ich habe es so weit geschafft, dass PiHole auf dem Fedora Server als Container läuft, von Clients in meinem Netzwerk erreichbar ist und DNS-Antworten liefert, wenn die Clients PiHole direkt kontaktieren. Sobald die Anfrage aber über die FritzBox läuft, endet sie in einem Timeout. Und das obwohl PiHole unter der gleichen IP und dem gleichen Port zu erreichen ist wie eh und je.

Habt ihr eine Idee, was hier das Problem sein könnte?

Viele Grüße
Martin

Timeouts werden häufig von einer DNS-Endlosschleife verursacht.

Verwendet Dein Pi-hole die FB als Upstream-DNS-Server oder ist Conditional Fowarding aktiv?

PiHole verwendet nur externe Upstream-DNS-Server, aber Conditional Forwarding ist tatsächlich aktiv. Die Einstellungen dafür sind exakt gleich zwischen PiHole im Docker-Container (wo es die Timeouts gibt) und der direkt installierten Version (die tadellos funktioniert). Muss man im Container hier etwas anders machen?

Treten die Timeouts denn noch auf, wenn Du Conditional Fowarding (CF) abschaltest?

Nebenbei: CF bringt absolut nichts, wenn die FritzBox Dein lokaler DNS-Server bleibt und Pi-hole nur als Upstream-DNS-Server in der FB eingetragen ist: Die einzige Client-IP, die dann in Pi-holes Query Log auftaucht, ist die Deiner FB.

Da hast du natürlich recht. Ich habe CF jetzt abgeschaltet. Leider macht das aber keinen Unterschied. Was mich auch wundert: Im Query Log erscheint die FritzBox nicht als Client, d.h. ihre Anfragen dringen gar nicht zum PiHole im Docker-Container durch.

Ich habe ein Debug-Log erzeugt und hochgeladen. Vielleicht hilft das, dem Problem auf die Spur zu kommen: https://tricorder.pi-hole.net/fese3nm0df

Das Problem liegt sehr wahrscheinlich in Deiner Netzwerkkonfiguration, wenn wir eine DNS-Schleife ausschliessen können. Schilderungen und Debug Log zeigen dafür pi-hole-seitig keinerlei Anzeichen.

Am wahrscheinlichsen wäre bei Deinem Fehlerbild, dass die FB ihre DNS-Anfragen nicht an Pi-hole weiterleitet, oder dass die DNS-Anfrage auf dem Weg zu Pi-hole blockiert wird.
Entsprechend solltest Du Deine FB-Einstellungen unter Internet | Zugangsdaten | DNS nochmals kontrollieren, und ebenso die Firewall auf Deinem Fedora-Server.

Welchen Netzwerk-Modus verwendest Du für Deinen Docker-Pi-hole?

Die FB-Einstellungen sind dieselben, egal ob PiHole im Container oder direkt auf dem Fedora-Server läuft, da das PiHole in beiden Fällen unter der gleichen IP zu erreichen ist. Die IP ist auch in der FB eingetragen.

Der Container läuft als root unter podman mit --net=private (Default).

Ich habe auch noch herausgefunden, dass die DNS-Anfragen von der FritzBox verschickt werden und auf dem Server ankommen. Allerdings schaffen sie es nicht zum PiHole im Container.

tcpdump auf Port 53 der Ethernet-Schnittstelle des Servers zeigt nämlich

19:44:54.468038 IP6 fd00::de39:6fff:fe2d:4a34.34664 > srv.mfs.name.domain: 21486+ [1au] A? dns-query-via-fritzbox.com. (55)

wenn ich von einem Client aus die FritzBox nach der IP von dns-query-via-fritzbox.com frage. Im pihole.log im Container erscheint die Anfrage allerdings nicht.

Das ist anders, wenn der Client direkt den Fedora-Server nach einer IP fragt.
tcpdump:

19:46:47.013381 IP6 fd00::676b:4450:7468:3996.53738 > srv.mfs.name.domain: 44532+ [1au] A? dns-query-from-client.com. (55)

pihole.log:

Oct 29 19:48:20 dnsmasq[675]: query[A] dns-query-from-client.com from fd00::676b:4450:7468:3996
Oct 29 19:48:20 dnsmasq[675]: forwarded dns-query-from-client.com to 2620:fe::9
Oct 29 19:48:20 dnsmasq[675]: reply dns-query-from-client.com is NXDOMAIN

Mit Anfragen über IPv4 sehe ich dasselbe Verhalten.

Irgendein Mechanismus muss also dafür sorgen, dass DNS-Anfragen von der FritzBox nicht zum PiHole kommen, Anfragen von anderen Clients aber schon.

Podman kann zwar Docker-Container laufen lassen, es ist aber nicht dasselbe wie Docker und unterscheidet sich intern mehr oder weniger stark von Docker. Da ich Podman noch nie eingesetzt habe und entsprechend nicht kenne, kann ich Dir leider ab hier nicht mehr wirklich weiterhelfen.

Deiner letzten Beschreibung nach würde ich vermuten, dass die von Podman realisierte Netzwerk-Isolation bestimmte Netzwerkverbindungen unterdrückt, wenn sie vom Gateway kommen, möglicherweise per iptables. Im einfachsten Fall hast Du einfach einen Netzwerk-Modus gewählt, der nicht zu Deinem Anwendungsszenario passt, oder Du musst tatsächlich manuell in die Filterregeln eingreifen.

Ob und wie man das ggf. in Podman beeinflussen kann, wäre eine Frage für jemanden, der sich mit Podman auskennt.
Wenn es ein Podman-Forum gibt, solltest Du die Frage auch dort platzieren.

Ich habe inzwischen noch mit tcpdump auf dem internen Interface des Containers herausgefunden, dass die DNS-Anfragen des Routers dort nie erscheinen, die Anfragen des Clients aber schon. Damit ist die Ursache eindeutig bei podman zu suchen. Ich habe dazu ein Issue angelegt. Falls ich auf diesem Weg eine Lösung finde, melde ich mich hier nochmal.

Vielen Dank für deine Unterstützung beim Debugging, @Bucking_Horn!

2 Likes

Inzwischen habe ich das Problem gefunden. In der Firewall des Fedora Servers war noch die Freigabe von Port 53/udp aktiv, weil das für den Betrieb des PiHoles ohne Container nötig war. Die aktive Portfreigabe im Zusammenspiel mit der Implementierung des Netzwerk-Stacks von Podman hat dazu geführt, dass Pakete vom Router bei Ankunft auf dem Fedora Server nicht an die private Container-IP, sondern an die Host-IP adressiert wurden. Seitdem ich die Portfreigabe gelöscht habe, funktioniert PiHole im Container einwandfrei.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.