Routing-Problem: zwei Geräte im gleichen WLAN mit unterschiedlichen Routen

[white_rabbit]

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!

[viragomann]

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?

[white_rabbit]

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??

[viragomann]

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.

[white_rabbit]

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:

Code: [Select]

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?

[viragomann]

Ist dieser DNS pihole auch im Wifi Netz?

[white_rabbit]

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)

[viragomann]

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.

[white_rabbit]

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

[viragomann]

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.

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.

[white_rabbit]

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

Wenn 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...

[viragomann]

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.

Deinen letzten Satz

Wenn 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. 

[Patrick M. Hausen]

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.

[viragomann]

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.

[Patrick M. Hausen]

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.