17
Alle DNS-Anfragen auf pfsense umleiten
Hallo,
ich habe hier folgende Konstellation:
Fritzbox 7490 am Telekom VDSL-Account
daran eine pfSense
hinter der pfSense die ganzen Clients
Die pfSense ist mein DNS im Netzwerk, es sind keine DNS-Server eingerichtet, folglich ist unbound aktiv und das geht alles direkt über die DNS-Root-Server...
Ich habe im NAT ein DNS-Redirect eingetragen (ist auf der Netgate-Seite in der Doku drin) - alle Anfragen auf Port 53 sollen an die 127.0.0.1 gehen. Die Firewall-REgeln wurden automatisch erstellt. Ich sehe in den Firewall-Logs auch, dass da was geblockt wird, aber wenn ich bei einem Windows-Client manuell den DNS 1.1.1.1 vorgebe und dann ein nslookup irgendwohin mache, sehe ich, dass die Antwort vom Cloudflare DNS kommt.
Ist das nur in Windows 10 eine falsche Anzeige oder geht das tatsächlich trotzdem über Cloudflare, obwohl die Regeln in der pfSense aktiv sind?
Ich habe zusätzlich noch die Ports 53, 853 geblockt bzw für das Ziel pfSense freigegeben, das ändert auch nichts dran.
Kann mir das jermand erklären?
Ich möchte das so haben, dass alle Netzwerkteilnehmer im Netzwerk ausschließlich den pfSense-DNS nutzen können, auch wenn ein anderer DNS z.B. irgendwo fest vorgegeben ist.
Beim ntp hab ich das auch so gemacht mit der Umleitung auf die pfSense, da weiß ich aber nicht, wie ich das weiter prüfen könnte... Ich sehe in den Firewall-Logs zumindest, dass da ausgehend was passiert.
ich habe hier folgende Konstellation:
Fritzbox 7490 am Telekom VDSL-Account
daran eine pfSense
hinter der pfSense die ganzen Clients
Die pfSense ist mein DNS im Netzwerk, es sind keine DNS-Server eingerichtet, folglich ist unbound aktiv und das geht alles direkt über die DNS-Root-Server...
Ich habe im NAT ein DNS-Redirect eingetragen (ist auf der Netgate-Seite in der Doku drin) - alle Anfragen auf Port 53 sollen an die 127.0.0.1 gehen. Die Firewall-REgeln wurden automatisch erstellt. Ich sehe in den Firewall-Logs auch, dass da was geblockt wird, aber wenn ich bei einem Windows-Client manuell den DNS 1.1.1.1 vorgebe und dann ein nslookup irgendwohin mache, sehe ich, dass die Antwort vom Cloudflare DNS kommt.
Ist das nur in Windows 10 eine falsche Anzeige oder geht das tatsächlich trotzdem über Cloudflare, obwohl die Regeln in der pfSense aktiv sind?
Ich habe zusätzlich noch die Ports 53, 853 geblockt bzw für das Ziel pfSense freigegeben, das ändert auch nichts dran.
Kann mir das jermand erklären?
Ich möchte das so haben, dass alle Netzwerkteilnehmer im Netzwerk ausschließlich den pfSense-DNS nutzen können, auch wenn ein anderer DNS z.B. irgendwo fest vorgegeben ist.
Beim ntp hab ich das auch so gemacht mit der Umleitung auf die pfSense, da weiß ich aber nicht, wie ich das weiter prüfen könnte... Ich sehe in den Firewall-Logs zumindest, dass da ausgehend was passiert.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 518951
Url: https://administrator.de/forum/alle-dns-anfragen-auf-pfsense-umleiten-518951.html
Ausgedruckt am: 21.04.2025 um 08:04 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
ein kurzer Blick ins umfangreiche Manual der PfSense ergibt folgendes:
Redirect All DNS to pfSense
ein kurzer Blick ins umfangreiche Manual der PfSense ergibt folgendes:
Redirect All DNS to pfSense
Das ist ja genau die Anleitung, nach der ich vorgegangen bin und auch die in dem Artikel erwähnte Blockierung von allen sonstigen DNS-Anfragen hab ich konfiguriert.
Wenn ich an meinem Windows 10 Client den Cloudflare-DNS manuell eintrage und dann nslookup mache, bekomme ich den 1.1.1.1 angezeigt.
Wird das auch angezeigt, wenn in Wirklichkeit die Anfrage vom pfSense beantwortet wurde oder müsste da bei einer Umleitung nicht stehen, dass ich die Antwort von 192.168.x.x zurück bekommen habe?
Wenn ich an meinem Windows 10 Client den Cloudflare-DNS manuell eintrage und dann nslookup mache, bekomme ich den 1.1.1.1 angezeigt.
Wird das auch angezeigt, wenn in Wirklichkeit die Anfrage vom pfSense beantwortet wurde oder müsste da bei einer Umleitung nicht stehen, dass ich die Antwort von 192.168.x.x zurück bekommen habe?
Zitat von @helloween:
Wenn ich an meinem Windows 10 Client den Cloudflare-DNS manuell eintrage und dann nslookup mache, bekomme ich den 1.1.1.1 angezeigt.
Das ist normal. Da die IP ja auch so eingetragen wurde.Wenn ich an meinem Windows 10 Client den Cloudflare-DNS manuell eintrage und dann nslookup mache, bekomme ich den 1.1.1.1 angezeigt.
Wird das auch angezeigt, wenn in Wirklichkeit die Anfrage vom pfSense beantwortet wurde
Ja.oder müsste da bei einer Umleitung nicht stehen, dass ich die Antwort von 192.168.x.x zurück bekommen habe?
Nein.Die pfSense macht ja einen transparenten Redirect und ändert die Zieladresse auf sich selbst, beim zurückschicken des Paketes an den Client ändert es die Quell-IP dann erneut auf 1.1.1.1, und der Client denkt er kommuniziert weiterhin mit 1.1.1.1, in Wirklichkeit redet er aber mit dem DNS der pfSense, er merkt es nur nicht.
Die pfSense spielt quasi transparenter Proxy für alle DNS-Anfragen.
REDIRECT ist intern einfach nur ein DSTNAT bei dem die Zieladresse auf die des eingehenden Interfaces umgeschrieben wird, da die Verbindung dann in der NAT Tabelle registriert ist werden Antwortpakete automatisch mit der Adresse als SRC Adresse versehen mit der sie eingegangen sind, also in deinem Fall mit der 1.1.1.1 und der Client bekommt davon nichts mit, er denkt er rede mit 1.1.1.1.
Alles in allem einfachstes Routing und NAT Grundlagenwissen
.
Aha, danke! Also passt bei mir alles... Ich war nur unsicher, weil da eben immer 1.1.1.1 stand bei nslookup.
Hab ja pfBlockerNG installiert, z.B. nslookup doubleclick.net ergibt --> 10.10.10.1 --> passt.
Reicht der Port 53 TCP/UDP oder müsste man nicht auch vorsorglich Port 853 auf die gleiche Weise umleiten?
Hab ja pfBlockerNG installiert, z.B. nslookup doubleclick.net ergibt --> 10.10.10.1 --> passt.
Reicht der Port 53 TCP/UDP oder müsste man nicht auch vorsorglich Port 853 auf die gleiche Weise umleiten?
Zitat von @helloween:
Reicht der Port 53 TCP/UDP oder müsste man nicht auch vorsorglich Port 853 auf die gleiche Weise umleiten?
Kannst du dir ja eigentlich auch selbst beantworten, Port 853 ist DNSoTLS, wenn also in deinem Netz ein Browser oder Device das Protokoll verwendet ist das für ihn eine Ausweichmöglichkeit die du nicht verarbeitest, den Rest kannst du dir selbst ausmalen, und funktionieren würde das nur wenn die pfSense Zertifikate als MitM ausstellt, die Verbindung muss ja TLS gesichert sein, ein simpler Redirect würde hier also niemals reichen denn die CA der pfSense müsste auf allen Clienst in den Root-Certs registriert sein! Noch wilder wirds wenn DNSoHTTPs erst mal richtig in Fahrt kommt.Reicht der Port 53 TCP/UDP oder müsste man nicht auch vorsorglich Port 853 auf die gleiche Weise umleiten?
Ok, dann reich mir eigentliche ein zusätzliche Regel, die Port 853 systemweit auf 127.0.0.1 / Port 53 umleitet, oder?
Zitat von @helloween:
Ok, dann reich mir eigentliche ein zusätzliche Regel, die Port 853 systemweit auf 127.0.0.1 / Port 53 umleitet, oder?
Nein, lies mal meine Ergänzung. DNSoTLS arbeitet mit Zertifikaten, ergo müsste die pfSense als MitM eigene Zertifikate ausstellen und am Client die CA der pfSense in den Roots registriert sein, damit diese nichts bemerken wenn diese auf TLS-"Strict" stehen.Ok, dann reich mir eigentliche ein zusätzliche Regel, die Port 853 systemweit auf 127.0.0.1 / Port 53 umleitet, oder?
Blocke Port 853 einfach, fertig. Die meisten Programme haben ein Fallback auf Port 53, also kein Problem.
wenn ich bei einem Windows-Client manuell den DNS 1.1.1.1 vorgebe und dann ein nslookup irgendwohin mache
Deshalb blockst du in den Regeln ja auch TCP/UDP 53 nach ANY und lässt es einzig und allein NUR auf die LAN IP der pfSense zu !!Etwas sinnvoll und intelligent nachdenken beim Erstellen des Regelwerkes sollte man schon !
Das hab ich doch alles schon gemacht - siehe meinen Beitrag oben, trotzdem hab ich in der Windows cmd die 1.1.1.1 zurück bekommen, daher war ich verunsichert.
Also ich habe im LAN > any/any < auf > ! LAN adress/port 53 < geblockt und direkt darüber ist die allow-Regel für den pfsense-DNS. Und natürlich immer TCP/UDP.
Also ich habe im LAN > any/any < auf > ! LAN adress/port 53 < geblockt und direkt darüber ist die allow-Regel für den pfsense-DNS. Und natürlich immer TCP/UDP.
trotzdem hab ich in der Windows cmd die 1.1.1.1 zurück bekommen, daher war ich verunsichert.
Dann ist deine Firewall Regel schlicht falsch !!Bedenke immer das da die reihenfolge zählt und immer die Grundregel First match wins ! gilt, sprich nach dem ersten positiven Hit wird der Rest NICHT mehr abgearbeitet !
Vermutlich liegt hier dein Fehler ?! Lässt sich wenigstens auf einer pfSense hier nicht reproduzieren !!
Deine Regel "LAN > any/any < auf > ! LAN adress/port 53 < geblockt" ist ja auch völlig falsch ! Auf die LAN Adress als Ziel darfst du das ja niemals blocken, denn die arbeitet doch gerade als Proxy DNS !
Richtig ist in der Reihenfolge:
PASS, Source: LAN_net, Port: any, Destination: LAN_address, Port: TCP/UDP 53
BLOCK, Source: LAN_net, Port: any, Destination: any, Port: TCP/UDP 53
So wird ein Schuh draus....
Das war etwas missverständlich ausgedrückt... Ich habe die Regel unter "Firewall - LAN" erstellt. any/any bezieht sich auf source/port.
Hier ein screenshot meiner Regeln:
Die ersten beiden Regeln wurden automatisch durch pfsense erstellt, weil ich dafür die NAT-Regeln laut pfsense-Doku erstellt habe.
Die block-Regel gilt doch nicht für LAN_address, sondern für ! LAN_address - also mit "!" --> alles ausser an LAN_address.
Hier ein screenshot meiner Regeln:
Die ersten beiden Regeln wurden automatisch durch pfsense erstellt, weil ich dafür die NAT-Regeln laut pfsense-Doku erstellt habe.
Die block-Regel gilt doch nicht für LAN_address, sondern für ! LAN_address - also mit "!" --> alles ausser an LAN_address.
Thema ist ja schon längst abgefrühstückt, also Case auch schließen bitte.
Und die 127er regeln sind völliger Unsinn und überflüssig ! Diese IP Adressen kann es physisch auf dem netz gar nicht geben. Diese Regeln sind also Blödsinn !
Die wurden aber genau so automatisch von der pfsense erstellt, weil ich das im NAT laut Doku umgeleitet habe. Also auf LAN adress ändern, oder?
Ich sehe aber, dass da was in der Firewall passiert und wenn ich im Windows Client die 1.1.1.1 als DNS vorgebe, dann zeigt es mir zwar beim nslookup dieselbe Adresse als DNS an, aber ich bekomme ebenfalls bei durch pfBlockerNG gesperrte Adressen mit der IP 10.10.10.1 zurück (dahin leitet pfBlockerNG die Werbung um...).
Also scheint es ja doch zu funktionieren, irgendwie...
btw:
Ist diese Firewall (selbst) und LAN address eigentlich das selbe, wenn ich eine Firewall-Regel erstelle? Damit zeigt die pfSense doch jedesmal auf sich selbst?
Ich sehe aber, dass da was in der Firewall passiert und wenn ich im Windows Client die 1.1.1.1 als DNS vorgebe, dann zeigt es mir zwar beim nslookup dieselbe Adresse als DNS an, aber ich bekomme ebenfalls bei durch pfBlockerNG gesperrte Adressen mit der IP 10.10.10.1 zurück (dahin leitet pfBlockerNG die Werbung um...).
Also scheint es ja doch zu funktionieren, irgendwie...
btw:
Ist diese Firewall (selbst) und LAN address eigentlich das selbe, wenn ich eine Firewall-Regel erstelle? Damit zeigt die pfSense doch jedesmal auf sich selbst?
Die wurden aber genau so automatisch von der pfsense erstellt
Dann hast du woanders DNS Blödsinn konfiguriert im DNS Setup. Im Default ist die pfSense immer DNS Proxy, man muss da gar nix einstellen und kann alles auf dem Default belassen.Der pfSense DNS bekommt dann den Upstream DNS automatisch per PPPoE vom Provider oder wenn man eine Kaskade hat mit statischer IP Adressierung trägt man die DNS IP (so gut wie immer die IP des am WAN Port kaskadierten Routers !) dann immer statisch im Basic Setup ein. Mehr ist nicht zu tun.
Keine Ahnung was du da verfummelt hast ?!
Im Default ist die pfSense immer DNS Proxy, man muss da gar nix einstellen und kann alles auf dem Default belassen.
@aqui lies mal alle Posts vorher, du bist auf dem völlig falschen Dampfer 
. Hier geht es nicht um die pfSense als DNS-Proxy an sich sondern darum das alle DNS Requests der Clients zwingend per transparentem Redirect auf die pfSense umgeleitet werden.
Ich hab keinen DNS-Forwarder eingetragen. Ich möchte das mit unbound machen, also dass die pfsense direkt bei den Root-DNS-Servern anfrägt und nicht den Google-DNS oder Cloudflare als Zwischenstation befragt...
Also per DHCP wird der DNS-Server schon an alle Clients richtig verteilt. Es gibt aber auch hin und wieder Endgeräte/Dienste/Apps oder was weis ich, in denen ein DNS-Server hardcoded ist und die will ich damit auf meinen eigenen umleiten.
Also per DHCP wird der DNS-Server schon an alle Clients richtig verteilt. Es gibt aber auch hin und wieder Endgeräte/Dienste/Apps oder was weis ich, in denen ein DNS-Server hardcoded ist und die will ich damit auf meinen eigenen umleiten.
