Hallo.
Wir haben hier ein merkwürdiges Routing-Problem. Im WLAN (Unifi Accesspoints, falls das relevant ist...) sind hier vormittags viele Geräte vorhanden.
Manche davon finden einen Rechner, der bei uns intern läuft und auf dem sich das MDM für die Geräte befindet aber nicht 100%ig zuverlässig sondern es gibt immer wieder Geräte mit Verbindungsproblemen.
Ich habe auf zwei iPads die App "Network Utils" verwendet, um mir das Tracerouting anzusehen. Auf einem Gerät, das alles richtig macht, läuft das so:
IP-Adresse des Gerätes (172.16.1.xy) -> OPNSense-Firewall (172.16.16.254) -> MDM (in der DMZ) unter 172.17.17.xy
Diese Route ist korrekt und es funktioniert so wie es sein soll.
Auf dem Gerät, das es falsch macht, sieht das aber so aus:
IP-Adresse des Gerätes (172.16.1.xy) -> Adresse im Internet (also nach draußen geroutet, obwohl es hier intern läuft)
Ich weiß leider nicht, warum das auf einigen Geräten manchmal so auftritt und wonach ich hier schauen soll?!? Als DNS-Server haben wir in dem WLAN für die Geräte ein Pi-Hole laufen, das wiederum die IP-Adresse des MDM-Servers richtig auflöst (das klappt auch auf allen Geräten korrekt!).
Aber die Route ist offenbar trotzdem manchmal falsch. Auf beiden iPads ist das gleiche Standard-Gateway und auch der gleiche DNS-Server eingetragen. Daher meine Frage, wo ich auf der OPNSense nachschauen soll, um das Problem eingrenzen zu können. Hat jemand einen guten Tipp für mich? Danke!
Quote from: white_rabbit on November 06, 2024, 12:13:55 PM
Auf dem Gerät, das es falsch macht, sieht das aber so aus:
IP-Adresse des Gerätes (172.16.1.xy) -> Adresse im Internet (also nach draußen geroutet, obwohl es hier intern läuft)
Die Adresse im Internet ist aber schon die der OPNSense, des Standardgateways?
Eigentlich sollte da die interne IP zuerst kommen, denn die sollte ja das Gateway sein.
Wenn Gerät versucht, die externe IP zu kontaktieren, sieht es mir doch eher nach einem DNS-Problem aus.
Offenbar wird nicht immer der interne DNS abgefragt.
Hast du eine Port Forwarding Regel gesetzt, die sämtliche Abfragen der Clients auf den internen DNS umbiegt?
Nein, "die Adresse im Internet" ist die IP-Adresse unserer Domain im Internet ... also eine "echte" / geroutete Adresse "da draußen". Als DNS-Server ist auf der OPNSense nur unser interner Server eingetragen, über den der Traffic laufen soll. Da das offenbar nicht immer funktioniert, muss es ja offensichtlich einen zweiten Weg geben ... der aber seltsamerweise nicht immer genommen wird.
Auf dem betroffenen Gerät ist es aber beispielsweise *immer* so, dass die Route nicht stimmt. Auch ein Verbinden mit einem anderen WLAN oder Neustart haben daran nichts geändert.
Eine Port Forwarding Regel für DNS habe ich aber bisher nicht gesetzt. Eigentlich sollte es doch klar sein, welcher DNS-Server verwendet werden soll, wenn ich den per DHCP-Server mit übergebe, oder??
Quote from: white_rabbit on November 06, 2024, 01:36:32 PM
Nein, "die Adresse im Internet" ist die IP-Adresse unserer Domain im Internet ... also eine "echte" / geroutete Adresse "da draußen".
Ich weiß nicht, was ich mir darunter vorstellen darf. Meine WAN IP ist auch eine echte öffentliche IP.
Aber egal, der Client versucht die öffentliche anstatt die lokale IP des Servers zu kontaktieren. Er ist vermutlich konfiguriert, auf einen bestimmten öffentlichen Hostnamen zuzugreifen und bekommt die IP dafür vom DNS.
Wäre interessant zu ermitteln, welches DNS er abfragt. Auch das lässt sich mit Paket Capture ermitteln, sofern er Standard-DNS or DoT nutzt (Ports 53, 853).
Ohne nähere Untersuchungen wirst du hier nicht weiterkommen.
Und es kommt darauf ein, wie der Client DNS handhabt. Normalerweise sollte ein Client den Resolver des Betriebssystems nutzen. Aber nicht immer ist das der Fall und sie entscheiden sich selbst für einen DNS Server. Dann bleibt ungeachtet, was im System eingetragen ist.
Eine Port Forwarding für DNS Anfragen schadet ja nicht.
Meine Regel als Beispiel im Anhang. Ich verwende den lokalen Unbound.
Wenn Client und DNS Server im selben Netzwerksegment sind, braucht es aber auch eine S-NAT (Masquerading) Regel dafür, um asymmetrisches Routing der Kommunikation zu verhindern.
Manche Clients nutzen auch DoH direkt. Das lässt sich nur über entsprechende Konfiguration oder bei ganz sturen mit Blocklisten unterbinden.
Ach so -- jetzt verstehe ich Deine Rückfrage. Nein, es ist noch etwas anders: Wir haben einen dedicated Server bei HostEurope gemietet, für den wir (www.)meine-domain.de hinterlegt haben.
Der befindet sich also mit fester öffentlicher IP direkt im Internet. Da läuft Plesk und auf dessen DNS-Server ist ein CNAME-Record hinterlegt, so dass beim Zugriff auf mdm.meine-domain.de an die WAN-Adresse hier im Netz weitergeleitet wird. Die Anfragen landen also bei der OPNSense, die sie dann via HAProxy an die jeweils richtige VM hier intern weiterleitet. Das ist also der Traffic, der von außen kommt und das funktioniert auch zuverlässig.
Das o.g. Problem taucht auf, wenn sich das Gerät bereits intern im Netzwerk befindet; aber dann wie gesagt auch nicht immer sondern nur bei manchen Geräten. Es ist daher schwer nachstellbar, da es auch zufällig immer wieder andere zu treffen scheint?! Wenn Du meinst, dass das ein DNS-Problem sein kann, will ich das gerne glauben.
Der Server mdm.meine-domain.de ist auf dem Pi-Hole natürlich direkt mit seiner internen IP 172.17.17.xy eingetragen, so dass der Traffic intern direkt dort landen soll -- ohne zuerst raus ins Internet zu müssen nur um dann wieder zurück zu kommen.
Vorhin habe ich diese Regel unter "Firewall: NAT: Portweiterleitung" erstellt (Attachment), die Deiner ja ganz ähnlich ist. Wenn ich diese Regel aber aktivieren, funktioniert die DNS-Abfrage in dem Subnetz gar nicht mehr.
Das sieht dann so aus:
nslookup heise.de
;; communication error to 172.16.16.253#53: timed out
Sobald sie wieder deaktiviert ist, läuft es wieder... etwas ist da offensichtlich faul. Hast Du noch einen guten Tipp, wie ich das herausfinden kann?
Ist dieser DNS pihole auch im Wifi Netz?
Ja, das ist er:
Gerade nochmal die DHCP-Einstellungen auf der OPNSense überprüft:
WLAN: 172.16.0.0 mit Subnetzmaske 255.255.0.0
DHCP-Bereich für die Clients im WLAN: 172.16.8.1 bis 172.16.15.254
DNS-Server: 172.16.16.253 (das ist das Pi-Hole)
Gateway: 172.16.16.254 (das ist die IP der OPNSense in diesem Subnetz)
Das ist schlecht, und zwar in zweifacher Hinsicht:
Einerseits, weil das Nicht-Funktionieren mit der NAT-Regel den eindeutigen Hinweis liefert, dass die Clients deinen pihole freiwillig gar nicht nutzen.
Und anderseits, weil du meine Empfehlung der Masquerading Regel ignoriert hast. Ich hatte ja geschrieben, dass das nötig ist, wenn Client und Server im selben Netz liegen. Nicht verstanden?
Okay, Masquerading:
Firewall: NAT: Outbound
Da mal den Hybrid Modus aktivieren, falls was anderes eingestellt ist, und speichern.
Eine Regel hinzufügen:
Schnittstelle: Wifi
Quelle: Wifi Subnetz
Ziel: 172.16.16.253
Ziel Port: 53
Translation: Wifi Adresse, also 172.16.16.254
Nachteil des Masqueradings: Der pihole sieht in allen Anfragen, die über die OPNsense gehen nicht die originale Client IP.
Wenn dir das nicht gefällt, müsstest du den DNS in ein eigenes Netzwerksegment bringen.
Hmmm - ja, das Masquerading bzw S-NAT habe ich bisher nicht eingestellt ... dafür aber die NAT-Reflektionen (hier gefunden): https://forum.opnsense.org/index.php?topic=7627.0
Was Du schreibst, passt aber nur halb ins Bild, denn ich sehe im Pi-Hole ja durchaus jede Menge Statistik und Zugriffe ... das scheint also grundsätzlich schon zu funktionieren?!
Die Sache, dass mit dem Masquerading "alle Anfragen, die über die OPNsense gehen nicht die originale Client IP sehen" ist natürlich unschön.
Die Outbound-Regel werde ich aber trotzdem schon mal erstellen und sie (temp.) aktivieren. Mal sehen, ob es das wirklich ist?
Also so, ja -> Attachment
Quote from: white_rabbit on November 06, 2024, 08:47:05 PM
Was Du schreibst, passt aber nur halb ins Bild, denn ich sehe im Pi-Hole ja durchaus jede Menge Statistik und Zugriffe ... das scheint also grundsätzlich schon zu funktionieren?!
Also für jene Clients, denen die Port Forwarding Regel ein Problem bereitet, gilt das sicher.
Auf Clients, die pihole direkt abfragen, würde sich die Regel gar nicht auswirken, und sollten trotz dieser funktionieren.
Quote
Die Sache, dass mit dem Masquerading "alle Anfragen, die über die OPNsense gehen nicht die originale Client IP sehen" ist natürlich unschön.
Wie sich das vermeiden lässt, habe ich geschrieben.
Ein Forwarding in dasselbe Netzwerksegment ohne Masquerading endet zielsicher in asymmetrischem Routing, und das ist jedenfalls für TCP Traffic in Problem.
Wenn NAT Reflection innerhalb desselben Subnetzes funktionieren soll, braucht es übrigens ebenfalls ein S-NAT auf die Interface IP.
Hallo.
Besten Dank für die Nachhilfe -- ich werde die Regel auf jeden Fall ausprobieren und schauen, ob der Fehler damit verschwindet. Das Stichwort
"asymmetrischem Routing" und die daraus resultierenden Probleme mit dem TCP Traffic würden jedenfalls ins Bild passen! Mir ist leider noch nicht ganz klar, in welchen Fällen bzw Subnetzen ich das S-NAT auf jeden Fall benötige aber das lässt sich ja vielleicht auch noch klären.
Deinen letzten Satz
QuoteWenn NAT Reflection innerhalb desselben Subnetzes funktionieren soll, braucht es übrigens ebenfalls ein S-NAT auf die Interface IP.
musst Du leider auch nochmal genauer erklären ... wo/wie muss ich
das einstellen?
Andererseits: Es scheint ja wirklich sehr viel unkomplizierter zu sein, wenn ich das Pi-Hole (VM auf Proxmox) einfach in ein anderes Subnetz lege (z.B. DMZ). Wenn das die Probleme direkt löst, kommt mir das viel einfacher vor...
Quote from: white_rabbit on November 06, 2024, 10:07:16 PM
Mir ist leider noch nicht ganz klar, in welchen Fällen bzw Subnetzen ich das S-NAT auf jeden Fall benötige aber das lässt sich ja vielleicht auch noch klären.
Wenn du einen TCP Request per Port Forwarding in dasselbe Subnetz zurück schickst.
Beispiel:
Subnetz: 10.0.0.0/24
OPNsense: 10.0.0.1
Server: 10.0.0.2
Client: 10.0.0.3
IP Pakete haben im Header immer die Quell-IP und die Ziel-IP. Damit weiß es, wo es hin muss, und das Zielgerät weiß dann, wer auf Antwort wartet.
Alle Geräte hängen an einem Switch. Pakete innerhalb des Subnetzes passieren nicht das Standardgateway, also OPNsense. Sie gehen z.B. vom Client über den Switch zum Server.
1. Client stellt eine DNS Anfrage auf 8.8.8.8. > Paket geht zum Gateway. (Quelle: 10.0.0.3, Ziel: 8.8.8.8 )
2. Die Portweiterleitung in OPNsense leitet es auf 10.0.0.2. (Quelle: 10.0.0.3, Ziel: 10.0.0.2)
3. Der Server erhält das Paket und schickt die Antwort auf die Quell-IP im Paket, also 10.0.0.3. (Quelle: 10.0.0.2, Ziel: 10.0.0.3)
4. Der Client erwartet aber keine Antwort von 10.0.0.3, den hat er ja auch nicht gefragt und ignoriert das Paket.
>> Es kommt keine Kommunikation zustande.
Nun aktivieren wir Masquerading.
1. Client stellt eine DNS Anfrage auf 8.8.8.8. > Paket geht zum Gateway. (Quelle: 10.0.0.3, Ziel: 8.8.8.8 )
2. Die Portweiterleitung in OPNsense leitet es auf 10.0.0.2. (Quelle: 10.0.0.3, Ziel: 10.0.0.2)
3. S-NAT setzt die Quell-IP in die Interface IP um und OPNsense speichert den Zustand der Verbindung. (Quelle: 10.0.0.1, Ziel: 10.0.0.2)
4. Der Server erhält das Paket und schickt die Antwort auf die Quell-IP im Paket, also 10.0.0.1. (Quelle: 10.0.0.2, Ziel: 10.0.0.1)
5. OPNsense weiß aufgrund der State Table, dass das ankommende Paket die Antwort auf die Anfrage des Clients ist und dass dieser ursprünglich 8.8.8.8 angefragt hatte, und schickt das Paket entsprechend dem an den Client weiter. (Quelle: 8.8.8.8, Ziel: 10.0.0.3)
6. Der Client bekommt das ersehnte Paket wie er es erwartet hat, ist glücklich und verarbeitet es.
Quote from: white_rabbit on November 06, 2024, 10:07:16 PM
Deinen letzten Satz
QuoteWenn NAT Reflection innerhalb desselben Subnetzes funktionieren soll, braucht es übrigens ebenfalls ein S-NAT auf die Interface IP.
musst Du leider auch nochmal genauer erklären ... wo/wie muss ich das einstellen?
Bei NAT Reflection macht es OPNsense automatisch, jedenfalls im Proxy Modus. Ob es das im normalen Modus auch tut, weiß ich nicht, ich verwende es nicht.
Mit Paket Capture kann man sich das ganze schön ansehen. Hatte ich schon empfohlen. ;)
Quote from: viragomann on November 06, 2024, 10:41:32 PM
1. Client stellt eine DNS Anfrage auf 8.8.8.8. > Paket geht zum Gateway. (Quelle: 10.0.0.3, Ziel: 8.8.8.8 )
2. Die Portweiterleitung in OPNsense leitet es auf 10.0.0.2. (Quelle: 10.0.0.3, Ziel: 10.0.0.2)
3. Der Server erhält das Paket und schickt die Antwort auf die Quell-IP im Paket, also 10.0.0.3. (Quelle: 10.0.0.2, Ziel: 10.0.0.3)
4. Der Client erwartet aber keine Antwort von 10.0.0.3, den hat er ja auch nicht gefragt und ignoriert das Paket.
Und deswegen verstehe ich bis heute nicht, wozu solche Weiterleitungen gut sein sollen.
1. Gib den Clients per DHCP dein PiHole oder was auch immer als DNS Server.
2. Blockiere alle das Netz verlassenden DNS-Requests außer denen vom PiHole ins Internet.
Fertig.
Quote from: Patrick M. Hausen on November 06, 2024, 11:08:59 PM
Und deswegen verstehe ich bis heute nicht, wozu solche Weiterleitungen gut sein sollen.
1. Gib den Clients per DHCP dein PiHole oder was auch immer als DNS Server.
2. Blockiere alle das Netz verlassenden DNS-Requests außer denen vom PiHole ins Internet.
Weil damit nicht jedes dumme Gerät funktioniert.
Es gibt IoT Geräte, die haben eine DNS IP fix eingebrannt. Erreichen sie diese nicht, versagen sie den Dienst.
Ich weiß, solche Geräte hat man nicht, aber man weiß das erst nach dem vermeintlich günstigen Kauf und dann möchte man ein Lösung.
OK - das war mir so tatsächlich nicht bewusst, solches Geraffel habe ich nicht. Daher danke.
Meine größte Sorge sind tatsächlich eigenmächtige Browser und DoH. Ich denke, die habe ich mit meinem Setup ganz gut im Griff.
Quote from: Patrick M. Hausen on November 06, 2024, 11:30:00 PM
Meine größte Sorge sind tatsächlich eigenmächtige Browser und DoH. Ich denke, die habe ich mit meinem Setup ganz gut im Griff.
Wenn du hier vielleicht einen Link zu einem Thread hättest, wo du das DoH Blocking erklärt hast, wäre ich dankbar.
Ich komme von pfSense. Da macht das der pfBlocker, den wohl fast jeder Überläufer erst mal vermisst.
Quote from: viragomann on November 06, 2024, 11:44:58 PM
Quote from: Patrick M. Hausen on November 06, 2024, 11:30:00 PM
Meine größte Sorge sind tatsächlich eigenmächtige Browser und DoH. Ich denke, die habe ich mit meinem Setup ganz gut im Griff.
Wenn du hier vielleicht einen Link zu einem Thread hättest, wo du das DoH Blocking erklärt hast, wäre ich dankbar.
Ich komme von pfSense. Da macht das der pfBlocker, den wohl fast jeder Überläufer erst mal vermisst.
Ich blocke ausgehendes DNS (UDP/TCP 53) und DoT (UDP/TCP 853) per Firewall-Regel und gebe allen Clients meinen AdGuard Home auf der OPNsense als Resolver. Letzteres per Portforwarding von LAN address:53 nach 127.0.0.1:53530. Funktioniert prima, primary DNS bleibt damit der Unbound, und in Server-Netzen, wo ich nicht filtern will, ist der auch der Resolver.
In AGH habe ich dann eine Blocklist für DoH-Server abonniert. Da DoH immer erst mal ein konventioneller Lookup vorausgeht, ist das das Beste, was man m.E. tun kann.
Okay, danke!
Adguard heißt hier das Zauberwort. Das habe ich noch nicht probiert. Habe da Hemmung, einen Kommerziellen Anbieter ins Spiel zu bringen.
Das Blocken der Ports mache ich soweit.
AdGuard Home - open source.
Wusste ich nicht.
Bin noch zu neu hier...
Github:
https://github.com/AdguardTeam/AdGuardHome
Zum Installieren auf OPNsense dieses Repo einbinden:
https://www.routerperformance.net/opnsense-repo/
Quote from: Patrick M. Hausen on November 06, 2024, 11:49:07 PM
In AGH habe ich dann eine Blocklist für DoH-Server abonniert. Da DoH immer erst mal ein konventioneller Lookup vorausgeht, ist das das Beste, was man m.E. tun kann.
Zur Ergänzung, wenn man noch eins drauf setzen möchte (auch aus meiner Sicht, sollte bereits das Blocken auf Domain-Ebene reichen): Es gibt zusätzlich zu den Blocklisten der DoH-Domains auch Listen mit IP-Adressen dieser Server (z.B. von HaGeZi (https://github.com/hagezi/dns-blocklists?tab=readme-ov-file#bypass_ips) oder DibDot (https://github.com/dibdot/DoH-IP-blocklists) aus dem OpenWRT-Umfeld).
Diese kann man dann einfach als Alias abonnieren und in den Firewall-Regeln verwenden.
Ein denkbares Problem wäre, dass auf den Servern auch noch andere Dienste laufen, welche man dann natürlich nicht mehr erreichen könnte. Aber in der Regel sind diese Server DoH-only.
Quote from: viragomann on November 06, 2024, 11:28:20 PM
Es gibt IoT Geräte, die haben eine DNS IP fix eingebrannt. Erreichen sie diese nicht, versagen sie den Dienst.
Ich weiß, solche Geräte hat man nicht, aber man weiß das erst nach dem vermeintlich günstigen Kauf und dann möchte man ein Lösung.
Du könntest noch anstatt DNS-Anfragen, welche nicht an deinen eigenen DNS-Dienst gehen, zu blocken diese Anfragen stattdessen umschreiben.
Sprich: Jegliches Paket aus dem LAN auf Port 53 was nicht an deinen Adblock-DNS-Server gerichtet ist, umleiten auf eben diesen.
Die Clients erhalten dann die Antwort nicht von dem Server den sie im Sinn hatten.
Aber Anfragen Richtung z.b. 8.8.8.8 kommen mit einer Antwort zurück.
Auf die Art erreichen die Clients ihren gewünschten Server scheinbar und sollten zufrieden sein, solange sie nicht die Authentizität des Servers anderweitig prüfen.
Quote from: Sylvan86 on November 07, 2024, 06:33:51 AM
Du könntest noch anstatt DNS-Anfragen, welche nicht an deinen eigenen DNS-Dienst gehen, zu blocken diese Anfragen stattdessen umschreiben.
Sprich: Jegliches Paket aus dem LAN auf Port 53 was nicht an deinen Adblock-DNS-Server gerichtet ist, umleiten auf eben diesen.
Genau das ist das Thema dieses Threads ;)
Hallo.
Ok, ich könnte natürlich vom Pi-Hole auf AdGuard wechseln. Installiert und eingerichtet ist das ja relativ schnell.
Dennoch ist mir eine Sache nicht ganz klar: Warum macht ausgerechnet der Traffic über DNS bzw das Pi-Hole hier das Problem, dass die Outbound-Regeln notwendig werden? Das Pi-Hole ist zwar im Moment im gleichen Netz wie die WiFi-Clients (wobei mir nicht bewusst war, dass das nicht so sein soll) -- aber was haben die DNS-Anfragen auf das Pi-Hole mit NAT zu tun?
Die Erklärung, warum man keine Regel im selben Netz der o.g. Form haben sollte, ist mir daher in der Theorie halbwegs klar -- nur: In der Praxis habe ich so eine Regel meines Wissens gar nicht eingerichtet.
Die Geräte, die hier im Einsatz sind, sind fast nur iPads -- also keine IoT-Geräte, wie sie weiter oben angesprochen wurden.
Kann natürlich sein, dass die iPads da irgendwas aus "convenience-Gründen" eigenmächtig einstellen oder sich einen eigenen DNS-Server aussuchen, wenn das vorgegebene aus irgendwelchen Gründen nicht erreichbar ist. Aber selbst dann sind das doch keine TCP Requests wie in dem o.g. Beispiel, oder?
Aber wie auch immer: Etwas stimmt hier im WLAN offensichtlich nicht und es ist super, dass ich jetzt einen guten Anhaltspunkt habe!
DNS-Clients ignorieren Antworten, die von anderen Adressen kommen als denen, an die sie die Anfrage geschickt haben.
Hatte @viragomann auch schon ausgeführt.
Client schickt Anfrage an 8.8.8.8.
Antwort kommt vom PiHole in deinem Netz.
Antwort wird ignoriert.
@Patrick
Danke nochmals für die Links.
Aktuell evaluiere ich OPNsense für den gewerblichen Einsatz. Soll dann auch eine Lizenz bekommen.
Da habe ich den Bedarf, DoH zu blocken, nicht. Ist ein reines Server-Netz.
Aber bei Gefallen stelle ich vielleicht meine Heim-pfSensen auch um. Dann wäre es doch interessant.
Quote from: Sylvan86 on November 07, 2024, 06:33:51 AM
Zur Ergänzung, wenn man noch eins drauf setzen möchte (auch aus meiner Sicht, sollte bereits das Blocken auf Domain-Ebene reichen): Es gibt zusätzlich zu den Blocklisten der DoH-Domains auch Listen mit IP-Adressen dieser Server (z.B. von HaGeZi (https://github.com/hagezi/dns-blocklists?tab=readme-ov-file#bypass_ips) oder DibDot (https://github.com/dibdot/DoH-IP-blocklists) aus dem OpenWRT-Umfeld).
Danke. Werde ich mir auch vormerken.
Ansonsten solltest du erst die Postings des Threads lesen. Wir haben das weitere schon lang und breit hier ausgeführt.
Quote from: white_rabbit on November 07, 2024, 09:18:13 AM
Ok, ich könnte natürlich vom Pi-Hole auf AdGuard wechseln.
Die OPNsense Konfiguration ist im Grunde für beide dieselbe, einzig...
Quote from: white_rabbit on November 07, 2024, 09:18:13 AM
Warum macht ausgerechnet der Traffic über DNS bzw das Pi-Hole hier das Problem, dass die Outbound-Regeln notwendig werden?
...das Problem ist, dass dein pihole im selben Subnetz läuft wie die Geräte,
deren Abfragen auf ihn umgeleitet sind.Ich will jetzt nicht zählen, wie oft ich schon versucht habe, das hier klarzustellen.
Der pi hat doch auch einen Kabelanschluss. Also nimm ihn und schließe ihn direkt an OPNsense an und gib ihm ein eigenes Subnetz, und alles ist gut.
Wenn deine Geräte ihr DNS Anfragen aus demselben Subnetz an den pihole schicken > kein Problem.
Wenn deine einen öffentlichen (oder irgendeinen außerhalb ihres Subnetzes) und abfragen > Abfragen gehen und OPNsense und werden da auf den pihole in dasselbe Subnetz zurück geleitet, kommt es zur asymmetrischen Paketvermittlung und der Client akzeptiert die Rückmeldung nicht, weil sie von der falschen IP kommt, sofern kein S-NAT gesetzt ist.
Deutlicher als im Beispiel oben, kann man das, denke ich, gar nicht mehr darstellen. Wenn du das nicht verstanden hast, lass Netzwerken besser bleiben.
Quote from: white_rabbit on November 07, 2024, 09:18:13 AM
Die Geräte, die hier im Einsatz sind, sind fast nur iPads -- also keine IoT-Geräte, wie sie weiter oben angesprochen wurden.
Die sind bekannt dafür, dass sie gerne DNS über HTTPS nutzen, und das kannst du schlecht umleiten, bestenfalls blockieren. Verschläge dafür wurden in diesem Thread auch schon gemacht.
(Nachtrag: Sorry @viragomann -- hatte Deine letzte Antwort vorher nicht gesehen, weil ich vermutlich gerade zeitgleich selbst geantwortet habe)
Screenshot 1: Ok, machen wir es konkret. Ich habe AdGuard auf der OPNSense installiert und auf Port 5310 in Betrieb genommen. Das ganze sieht dann so aus.
Screenshot 2: Offenbar läuft der Service also und beantwortet Anfragen auf Port 5310 auf den beiden angegebenen Adressen.
Screenshot 3: Aus dem Netz 192.168.1.0/24 wird gemeldet: Der Port ist offen -- da kommen die Anfragen auch bei der OPNSense bzw beim AdGuard an. Das habe ich ausprobiert.
Funktioniert alles so wie es sein soll...
Aber ...
Zum ganzen NAT Reflection Thema hab ich mal einen größeren docs Artikel verfasst. Da werden auch die Probleme erklärt wie Source NAT für Geräte im gleichen Netzwerk.
https://docs.opnsense.org/manual/how-tos/nat_reflection.html
Aber man sieht in den weiteren Screenshots das Problem. Ich habe dann das gleiche von einem Client im WLAN gemacht.
Hier die Screenshots:
In Screenshot 1 sieht man, dass der Port nun als "Closed" gemeldet wird -- verstehe ich nicht!?
In Screenshot 2 (s.u.) habe ich Wireshark benutzt und zunächst eine reguläre DNS-Anfrage über Port 53 an die OPNSense geschickt -- die kommt an.
In Screenshot 3 (s.u.) habe ich mit Wireshark untersucht, was mit einer Anfrage auf Port 5310 los ist. Das kommt offenbar nicht ... bleibt die Frage, warum der Port angeblich dicht ist?
Wenn ich das gleiche über die OPNSense selbst mache, funktioniert es:
dig heise.de @172.16.16.254 -p5310
von der OPNSense aus liefert das richtige Ergebnis.
Screenshot 2:
Screenshot 3:
Quote from: Monviech on November 07, 2024, 11:24:52 AM
Zum ganzen NAT Reflection Thema hab ich mal einen größeren docs Artikel verfasst. Da werden auch die Probleme erklärt wie Source NAT für Geräte im gleichen Netzwerk.
https://docs.opnsense.org/manual/how-tos/nat_reflection.html
Ok, das habe ich ausgedruckt, gelesen und verstanden -- besten Dank ;)
Das aktuelle Problem mit dem AdGuard liegt offenbar einfach nur daran, dass da eine Regel fehlte. Ich habe diese Regel zusätzlich erzeugt und schon gingen die Anfragen durch: