Keine DNS-Auflösung in der DMZ
-
@alcamar said in Keine DNS-Auflösung in der DMZ:
Du meinst also, das wäre nicht zwingend notwendig gewesen den DNS-Eintrag im DHCP-Server der DMZ vorzunehmen?
Nein, wie gesagt, ist das Feld leer, wird die Interface IP als DNS an die Clients geschickt.
die /etc/resolv.conf hatte ich schonmal geändert. Das ist recht umständlich, weil die Datei immer wieder neu (von resolvconf) generiert und überschrieben wird. Man kann der Datei dann ein Attribut verpassen, damit auch root die dann nicht überschreibt.
sudo chattr -f +i /etc/resolv.confBei der Raspi Konfig kann ich auch nicht helfen. Ich denke aber, es sollte möglich sein, den DNS Server manuell zu setzen.
Vor allem macht der "fixe" Eintrag von localhost nur dann Sinn, wenn auf dem System selbst ein DNS Server läuft. Ist das vielleicht so?Das hat aber nichts gebracht, weshalb ich mit bestätigt sah, dass das Problem in der pfsense versteckt sein muss.
Ich würde davon ausgehen, dass die pfSense alles richtig macht. Aber du kannst es ja mit einem Packet Capture überprüfen. Das DHCP Protokoll kann man schön mitlesen.
Lass einfach ein Capture am jeweiligen Interface mit dem Portfilter "67|68" laufen, während der Raspi eine neue IP vom DHCP ziehen soll und schau dann, was die pfSense an den Client übermittelt.
Du kannst natürlich stattdessen auch am Raspi ein tcpdump laufen lassen. -
@viragomann beim capture mit 67|68 und reboot vom raspi passiert gar nichts. Leer! Das erklärt vermutlich, dass die raspi mit der pfsense gar nicht kommuniziert, zumindest IP und DNS
-
@alcamar
Ich würde das mal so interpretieren, als dass er keinen DHCP Client laufen hat. D.h., dass er eine feste IP Einstellung hat. Die müsstest du dann manuell konfigurieren. Dann ist natürlich auch den DNS Server manuell zu setzen. -
@viragomann ja, ist habe statisch gesetzt:
- DNS
- IP
- Router
trotzdem keine chance. Versuche gerade den DHCP-Client auf der Raspi zum Laufen zu bekommen und dann es neu zu versuchen.
-
@alcamar said in Keine DNS-Auflösung in der DMZ:
ja, ist habe statisch gesetzt:
DNS
IP
RouterDie Netzwerkmaske wäre noch wichtig. Aber dann sollte eine Verbindung möglich sein.
Geht da nichts, in keine Richtung?
Auch keine ARP-Einträge in den Tabellen?Wenn die IP auf DHCP gesetzt wird, sollte der Client arbeiten.
Die Netzwerkmaske muss auch auf pfSense passen, damit die Geräte kommunizieren können.
-
@viragomann
Aus meiner Sicht ist die Maske ok.
ARP-Eintrag in der pfSence mit der IP des RASPI ist vorhanden.@viragomann said in Keine DNS-Auflösung in der DMZ:
Die Netzwerkmaske muss auch auf pfSense passen, damit die Geräte kommunizieren können.
wo meinst Du?
Ich komme auf den RASPI per HAProxy von außen rein. Das Ding ist im Netz. Nur die Namensauflösung geht nicht über die pfSense
-
@alcamar
Das sieht eh soweit in Ordnung aus, doch wird kein DNS-Server hinzugefügt und IPv6-Anfragen werden anscheinend nicht beantwortet, ist aber auch nicht nötig.Aber dann müsste die DHCP Kommunikation auch im Packet Capture zu sehen sein.
Es würde nur zeigen, dass pfSense einen DNS Server zuweist.Dann musst du den DNS irgendwie manuell einstellen können.
Wenn die /etc/resolv.conf überschrieben wird, muss es doch eine andere Möglichkeit der Konfiguration geben. -
@viragomann Die manuelle permanente Zuweisung in der /etc/resolv.conf hat nichts gebracht. Die Namensauflösung geht nicht.
Ich habe ein ganz neues Raspi 4 aufgesetzt. Nur das blanke, ganz neu Raspi OS, mit DHCP-Client.
-
Zuerst an der pfSense angebunden: gleiches Phänomen. Namensauflösung geht nicht. Aber /etc/resolv.conf ist richtig generiert.
-
Danach an der FritzBox angebunden: ping www.google.com geht.
Damit denke ich, dass meine Lösung in der pfSense liegt. Nur wo fällt mir nix mehr ein. Ich finde auch keine Hinweise im Netz, dass sich pfSense und Raspi nicht DNS-mäßig vertragen.
-
-
Was zeigt der Pi denn an bei?
ip a
ip r
cat /etc/resolv.confStimmt per DHCP, die IP, die Maske, das Gateway und der DNS ist auch sauber eingetragen, sind private Ips, bis auf deine Public Domain, kannst hier ruhig alles zeigen.
-
ich vermute, dass ich den (bzw. einen) Fehler gefunden habe.
Auch wenn ich die Auswirkung nicht kapiere und auch nicht mehr weiß, warum ich beim Konfigurieren diesen Eintrag gemacht habe.
Ich habe die Regel auskommentiert, die mit Port 53 (DNS) etwas zu tun hatte.Ich hoffe, dass ich einen Weg der Qualitätssicherung finde, wenn ich mit der Einrichtung der pfSense fertig bin. Viele Fehler erkennt man mit der Hilfe dieses Forums, für das ich sehr dankbar bin. Danke für Eure Hilfe!
Aber vermutlich sind noch viele Fehler in meiner pfSense vergraben, die einfach nur gefährlich sind, aber keine sichtbare Fehlfunktion generieren.
Gerade bei der Definition von Regeln habe ich nicht das Gefühl exakt zu kapieren, was da passiert. :-( -
@alcamar
Das ist eine Port Farwarding Regel von DNS auf die pfSense localhost Adresse.
Standardmäßig nimmt der DNS Resolver Anfragen auf allen Interface IPs entgegen und dieses Forwarding sollte nicht nötig sein. Außerdem ist sie nur am LAN, nicht auf der DMZ existent.Damit denke ich, dass meine Lösung in der pfSense liegt. Nur wo fällt mir nix mehr ein.
Du solltest keine Vermutungen anstellen, sondern die Fakten überprüfen.
@NOCling hatte dazu ein paar Fragen gestellt. Antworten könnten da sehr hilfreich sein.Auch interessant wäre, welche DNS IP der Raspi für die Auflösung tatsächlich nutzt. ein dig oder nslookup, was er immer installiert hat, würde das zeigen. Dann braucht es keine Spekulationen.
-
@viragomann dann versuche ich es konkreter mit den Fakten. Diese Einstellung ist definitiv diejenige, die meine Problem gelöst hat.
Und leider ist auch ein Fakt, dass ich persönlich noch nicht dahintergestiegen bin warum. Mit Deiner Rückmeldung (LAN) komme ich vielleicht noch dahinter, obwohl sie sich dennoch definitiv auf die DMZ auswirkt.Anhand der Beobachtungen war meine Arbeitshypothese, dass es an der pfSense liegen muss. Diese Vermutung hat sich bestätigt.
@NOCling Fragen und Anregungen, gingen auch meiner Sicht in eine andere Richtung, nämlich dass man sich die Raspi genauer anschauen müsste. Das hatte ich aber ja bereits und auch, dass ich die /etc/resolv.conf länger bearbeiten musste, damit sie auch den richtigen DNS-Server permanent speichert. Das war so ziemlich der Anfang meines Posts. Ich hätte seine Fragen dennoch noch beantwortet.
@viragomann said in Keine DNS-Auflösung in der DMZ:
Auch interessant wäre, welche DNS IP der Raspi für die Auflösung tatsächlich nutzt. ein dig oder nslookup, was er immer installiert hat, würde das zeigen. Dann braucht es keine Spekulationen.
Auch in meinem Initialbeitrag hatte ich erwähnt dass, dig, traceroute, nslookup nicht gingen. Jetzt geht nur noch traceroute nicht. Habe dies aber zunächst nicht weiter verfolgt.
-
J jimp moved this topic from DHCP and DNS on
-
@alcamar said in Keine DNS-Auflösung in der DMZ:
Anhand der Beobachtungen war meine Arbeitshypothese, dass es an der pfSense liegen muss. Diese Vermutung hat sich bestätigt.
Wenn man haufenweise Regeln hat, von denen man nicht genau weiß, was sie eigentlich tun, dann ist die Vermutung richtig, dass es an deinem Regelwerk liegt. Die besagte Regel wirkt sich aber nur auf LAN aus. Es kann aber sein, dass Du irgendwelche verqueren Regeln drin hast, die man so eigentlich nicht nutzen sollte... vermutlich ist dein Raspi im LAN und nicht in der DMZ.
-
@bob-dig wenn Du damit sagen willst, dass ich haufenweise keine Ahnung habe, muss ich Dir Recht geben. :-) Ich versuche mich langsam in die Materie einzuarbeiten. Zuvor war für mich die FritzBox das Maß aller Dinge.
Die Raspi ist im Adressraum (10.10.1.0/24) der Netzwerkarte, die die DMZ bildet. Bei den DHCP Leases taucht sie auch nur einmal auf. Mein LAN ist 192.168.1.0
Vielleicht habe ich aber auch haufenweise, unnötige Regeln, die aus verschiedenen Tuts zusammengezimmert sind. -
@alcamar said in Keine DNS-Auflösung in der DMZ:
Die Raspi ist im Adressraum (10.10.1.0/24) der Netzwerkarte, die die DMZ bildet. Bei den DHCP Leases taucht sie auch nur einmal auf. Mein LAN ist 192.168.1.0
Vielleicht habe ich aber auch haufenweise, unnötige Regeln, die aus verschiedenen Tuts zusammengezimmert sind.Ja die sind leider so eine Crux. Viele Blogs oder Tutorials bleiben ewig online, beziehen sich aber auf steinalten Kram den es nicht mehr gibt. Es wird aber trotzdem schön abgearbeitet statt sich an die eigene Doku (bspw. pfSense Docs) zu halten ;)
Kommt vor. Daher würde ich da Stück für Stück erstmal nur die Regeln erzeugen, die Sinn machen. Bspw. macht die Regel die du disabled hast per se keinen Sinn dass die sich auf die DMZ auswirkt. Aber die Regel war ja ein Teil von einer NAT Rule - und die haben wir nicht gesehen. Vielleicht hast du ja NAT Regeln etc. die dir da reingrätschen und deshalb das alles so wirr ist.
Darum mit so wenig wie möglich simpel testen und sich dann langsam vorantasten, dann sollte das auch klappen. :)
Cheers
-
Mit NAT kann man viel geiles Zeugs anstellen, aber man muss dabei immer aufpassen!
Ich sorge hier per NAT dafür, dass nur die pfSense als DNS Server angesprochen wird.
Nur so kann ich pfBlocker effektiv nutzen und man kann ich nicht so einfach unterwandern.
Dank DNS über HTTPS muss man aber immer wieder einen Blick drauf haben, da immer wieder neue Server dazu kommen, die Liste müssen also passen.Also zeige doch mal deine NAT Regeln.
-
@nocling guter Hinweis, da ich pfBlocker auch einsetze und Pihole deaktiviert habe.
Meine NAT Regeln hatte ich vor zwei Tagen bereits gepostet (s.o.), wenn Du die meinst. Aber vermutlich fehlt der Vollständigkeit wegen noch die Rubrik Outbound:
1:1 und NPt sind leer.
Ich bin noch im Aufbau begriffen. Die vorgeschlagene Herangehensweise von @JeGr ist die richtige, nämlich schrittweise nur die benötigtem Regeln zu implementieren. Manchmal probiert man aber (verzweifelt) aus und vergisst auch nach einem Fehlversuch den Ursprungszustand wieder herzustellen. Ich will deshalb Regeln in der Beschreibung so kennzeichnen, dass sie testweise oder produktiv im Einsatz sind. Das wäre ein nettes Feature für ein Flag in pfSense. (Analog bei ACME die Unterscheidung Staging und Prod)
-
Ah ja ok stimmt, die DNS Regel auf Localhost mache ja Sinn, aber nur wenn das Ziel !This Firewall ist.