Messages

Hallo.
Ich habe zufällig dieses Video gefunden und wüsste gerne, ob das os-caddy-Plugin direkt auf der OPNSense in größeren Umgebungen mithalten kann? Weiß jemand genaueres? Danke.
https://www.youtube.com/watch?v=N5PAU-vYrN8

Hallo.
Wir haben hier immer wieder Probleme mit Geräten im WLAN (iPads), die von unserem MDM Befehle annehmen sollen. Scheinbar kommen diese Änderungen nicht immer zuverlässig genug bei allen Geräten an!?

Ich habe mir daher nochmal diese Seite angesehen:
https://support.apple.com/de-de/guide/deployment/dep2de55389a/web
Es ist also so, dass alle Geräte im WLAN Kontakt über Port 5223 zu Apple aufbauen können müssen:
"Durch die Verwendung von APNs werden Apple-Geräte über Aktualisierungen, MDM-Richtlinien und eingehende Nachrichten informiert."

Bei uns sieht die Regel für die Portweiterleitung so aus (s. Attachment). Ist das so richtig? Oder ist diese Regel überflüssig?
Was seltsam an der Sache ist: viele Clients im WLAN bekommen eine Änderung durch das MDM direkt mit ... aber es gibt immer wieder einzelne Geräte, die entweder gar nicht oder erst sehr viel später reagieren, wenn eine Aktion vom MDM ausgelöst wird.
Daher dachte ich, dass evtl die Einstellungen zum Port 5223 nicht ganz korrekt sind? Wie seht ihr das?

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:

Screenshot 3:

Screenshot 2:

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:

Code Select Expand


dig heise.de @172.16.16.254 -p5310

von der OPNSense aus liefert das richtige Ergebnis.

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

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!

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

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

[(das ist das Pi-Hole)]

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)

[außen]

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 Expand


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?

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

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!

Alles klar -- das ist der Fall. Da steht tatsächlich:
option dhcp-lease-time 1800;
Danke für die Info.
Dann lasse alles so wie es ist.