TP Link Omada Neuling hat Probleme - verschiedene VLANS Teils verbinden / Teils trennen

[raspido]

Ich habe mich gerade mit dem Support von TP Link mal per Telefon in Verbindung gesetzt, die Telefonverbindung war nicht optimal gewesen und somit hat mich der Mitarbeiter gebeten, eine E-Mail zu verfassen, was ich auch dann direkt über das Kontaktportal von dene gemacht habe. Nun warte ich auf Antwort.

Einen Versuch haben wir trotz etwas sprachlicher Probleme zu Testen. Bzw. er sagte mir ich sollte das Standart VLAN 1 nicht nutzen, sondern den PC in ein "eigen erzeugtes VLAN" packen. Da das "Standart VLAN" nicht funktionieren würde. Dies habe ich auch gemacht. Also neues VLAN (LAN 2 (Nicht kreativ ich weiß)) erzeugt, Port am Switch auf das neue VLAN eingestellt (an dem der PC hängt und diesen mit einer neuen IP ausgestattet), WLAN auf dieses VLAN "umgebogen", Switch ACL Regel von VLAN 1 (mit dem Namen LAN) auf das neu angelegte Netzwerk verändert. Keine Änderung zu dem davor.

Die Regel mit der ich explizit alle Protokolle vom neuen Netzwerk ins IoT Netzwerk erlaube, habe ich auch angepasst und aktiviert. Dies brachte auch kein Fortschritt. Da war auch egal, in welcher Reihenfolge ich die Regeln einstelle. Also ob Regel 1 das "verbieten" von allem von "IoT" nach "LAN 2" und Regel 2 das "erlauben" von "LAN 2" nach "IoT" oder andersrum.

Also alles in allem brachte bislang noch nicht so wirklich den Fortschritt. Ich bin gespannt, was vom Support kommt, bzw. ob ich so das Problem beseitigt bekomme. Hab noch bis zum 12.11. Zeit um mich zu entscheiden. Also bis dahin muss ich notfalls die Retoure an Amazon veranlassen. Was eigentlich schade wäre, den bis auf das "Problem" bin ich eigentlich von dem System ganz angetan.


Michael

 

[raspido]

Wollte nur mal bescheid geben, nach über 24h vom TP-Link Support noch nichts gehört per E-Mail. Mal gucken ob da noch was kommt.

 

[Datax]

Habe folgendene Artikel gefunden, die dein Problem erklären könnten:

Switch ACL's don't act as expected:
https://community.tp-link.com/en/business/forum/topic/552572
TP-Link Omada - Switch ACLs aren't stateful:
https://www.reddit.com/r/HomeNetworking/comments/mrxsbg/tplink_omada_switch_acls_arent_stateful/

Die ACLs/Firewall-Regeln bei "Omada" sind nicht "stateful". Sprich, die Firewall deines Routers erlaubt zwar den Aufbau / das Initiieren von Verbindungen in die Richtungen wie sie in den ACLs als "erlaubt" konfiguriert wurden, die Antwortpakete werden allerdings nicht automatisch erlaubt.

Es gibt bei "Omada" also kein SPI (Stateful Packet Inspektion).

Wenn du dein Vorhaben umsetzen möchtest, musst du bei "Omada" also immer pro zu erlaubende Verbindung beide Kommunikationsrichtungen per Firewall-Regel erlauben. Die Kommunikationsrichtung der Antwortpakete muss also über eine eigene Firewall-Regel erlaubt werden. Allerdings ist das aus Security-Sicht bedeutend schlechter als wenn die Firewall die Antwortpakete automatisch (mit Hilfe der SPI-Funktionalität) erlaubt.

Um zum Beispiel den Zugriff aus dem LAN heraus in Richtung eines Webservers im IoT-Netz (ich weiß, doofes Beispiel ^^) zu erlauben, müsstest du wie gesagt beide Kommunikationsrichtungen erlauben (weil kein "Stateful Packet Inspection").

1. Regel:
LAN -> Webserver:80 -> Datenverkehr erlauben

2. Regel:
Webserver:80 -> LAN -> Datenverkehr erlauben

Über Block- bzw. Deny-Regeln kannst du im Anschluss jeglichen Datenverkehr blocken / sperren,
der nicht erlaubt sein soll. Die Regeln werden von oben nach unten abgearbeitet, weshalb die Reihenfolge der Regeln natürlich wichtig ist.

Wie oben erwähnt ist ein Firewall-Regelwerk mit "SPI" aus Security-Sicht deutlich besser, weil es bei einer Firewall ohne "SPI" bei obigem Beispiel möglich ist, dass ein super-gemeiner Angreifer mit seinem Hacker-Cracker-Angreifer-Tool über Quell-Port 80 eine Verbindung aus dem IoT-Netz in Richtung deines LANs aufbauen kann, obwohl du selbst eigentlich nur LAN -> Webserver:80 sowie die entsprechenden Antwortpakete erlauben wolltest.

Vielleicht kannst du einfach mal beim TP-Link-Support nachfragen, ob sich in Zukunft (z. B. durch entsprechende Firmware-Updates) etwas an den ACLs bezüglich "Stateful Packet Inspection" was tut.

 

[raspido]

@Datax: Danke für deine Super Antwort. Ich habe heute mit einem Kollegen nochmal über alles drüber geguckt und naja entschieden alles wieder einzupacken und zurück zum Händler zu schicken.

Wie oben schon mal gesagt, telefonisch war das mit dem Support nur bedingt brauchbar und naja nach 24 Stunden habe ich auf Email auch noch nichts gehört. Mal gucken ob noch was kommt. Werde es aber bei TP-Link auf jedenfall nochmal ansprechen, wie es mit dem erwähnten Statful Paket Inspektion aussieht. Mal gucken ob ich dazu eine Antwort bekomme.

Wollte es aber nun mal mit den Geräten von Unify probieren. Vielleicht habe ich da mehr Erfolg. Ist zwar alles in allem teurer. Aber naja mal gucken. Werde euch aber auf jedem Fall auf dem laufenden halten. Also egal ob es um eine Antwort von TP Link geht oder um den neuen Versuch mit Unify Gerätschaften.


Michael

 

[Datax]

Wie oben schon mal gesagt, telefonisch war das mit dem Support nur bedingt brauchbar und naja nach 24 Stunden habe ich auf Email auch noch nichts gehört. Mal gucken ob noch was kommt. Werde es aber bei TP-Link auf jedenfall nochmal ansprechen, wie es mit dem erwähnten Statful Paket Inspektion aussieht. Mal gucken ob ich dazu eine Antwort bekomme.

Der Zustand, dass man bei "Omada" auf "Stateful Inspection" verzichten muss, ist leider schon seit Jahren so. Vermutlich seit diese Geräte auf den Markt gekommen sind. Bin gespannt auf die Antwort von "TP-Link", falls der Support sich im Laufe der nächsten Tage mal melden sollte.

Wollte es aber nun mal mit den Geräten von Unify probieren. Vielleicht habe ich da mehr Erfolg. Ist zwar alles in allem teurer. Aber naja mal gucken. Werde euch aber auf jedem Fall auf dem laufenden halten. Also egal ob es um eine Antwort von TP Link geht oder um den neuen Versuch mit Unify Gerätschaften.

Bei "Unify" ist auf jeden Fall "Stateful Inspection" vorhanden. Die "UDM Pro"-Firewall zum Beispiel kann es (siehe Link unten) und die "EdgeRouter-Serie (z. B. der "ER-X") unterstützt es ebenfalls.

UniFi Gateways - Introduction to Firewall Rules:
https://help.ui.com/hc/en-us/articles/115003173168-UniFi-UDM-USG-Introduction-to-Firewall-Rules

Ich wünsche viel Erfolg bei der Konfiguration der Unify-Gerätschaften :-).

 

[raspido]

Moin,

weiß ich Bescheid. Ich hoffe beim Unify Dream Router klappt das auch. Den habe ich über einen Bekannten bekommen und der würde mir einiges erleichtern. Vor allem das "Basissetup" bevor ich in den Vollproduktivmodus gehe. Also ich wollte es erst im kleinen Testen, nicht das ich Hardware von 2000€ oder so rum liegen habe und es nicht zum gewünschten Ergebnis führt.

Aber sobald ich das Gerät in Händen halte, kann ich es praktisch testen und gucken was das Ding kann.


Michael

 

[raspido]

Nabend Leute,
heute kam mein Dream Router von Unify. Ich hab alles wie beim TP Link in der Reihenfolge und so eingestellt bzw. eingerichtet und ich muss sagen. Es läuft tadellos.


Mit "Basiseinrichtung" des Dream Routers und erstellen aller 3 VLANs / Netzwerke, aller 3 WLANs, Regel erstellen und ein paar Sachen suchen, knapp eine Stunde und es läuft, wie ich es haben möchte. Besser gesagt, wie ich es schon zu Beginn haben wollte. Also Hauptnetzwerk kommt auf Geräte im IoT Netzwerk, aber Geräte aus dem IoT Netzwerk kommen NICHT ins Hauptnetzwerk.


Ich bin da echt total begeistert. Vor allem vom Preis / Leistung ähnliche Richtung, eher etwas günstiger als mein "Basissetup" bei TP Link. Also der Dream Router, bringt ja schon den Controller, ein 4 Port Switch (davon 2 POE), einen AP und den Router mit. Alles in einer kleinen weißen Dose mit blauem Ring.


Das Display im Gerät hätte man sich zwar "kneifen" können, also ist ganz witzig aber über den Sinn und Unsinn muss man sich nicht unbedingt streiten.


Also falls jemand was ähnliches vor hat wie ich, erster Eindruck, klasse. Ich lass die Kiste nun mal paar Tage laufen und guck mal was passiert. Bislang sind lediglich 2 Wemos D1 Minis per WLAN verbunden (je einer pro Netzwerk), mein PC (per LAN) und ein Windows Tablet per WLAN. Weitere Geräte werde ich zum Wochenende denke ich hinzufügen.


Nochmal danke, an alle die mir helfen wollten bzw. geholfen haben. War echt klasse. Mal gucken ob alles bei UniFi so gut läuft wie bislang, aber bislang echt klasse. Die Einstellungen waren zum Teil etwas anders bezeichnet, bzw. manche Einstellungen waren, als Standart im Automode gewesen (VLAN ID, IP Bereich und ähnliches). Kleiner Manko der Lüfter macht etwas Geräusche, dass hatte ich aber vorher schon wo gelesen gehabt und naja, er wird nicht im Schlafzimmer stehen, dann stört es mich nicht. Sobald Testphase abgeschlossen ist, kommt das Teil eh an den Platz der FritzBox und das ist im Durchgang zwischen Wohn und Esszimmer.


Bei Fragen, einfach was sagen ich geb gern das weiter, was ich zumindest kann.


Michael


PS: Bezahlt habe ich für den Dream Router um 270€

 

[raspido]

Ich weiß nicht ob das die beste Entscheidung ist, oder ggf. total ins Auge geht.

Aber ich bin nun mal etwas weiter gegangen mit dem ganzen UniFi Zeug und im großen und ganzen bin ich auch noch total begeistert.

Aber ein Problem mit der Firewall des DreamRouters tritt mir aktuell ordentlich auf die Füße und irgendwie komme ich nicht dahinter, wo das Problem sitzt.

Ich habe noch ein weiteres VLAN dem ganzen Hinzugefügt (Server Netz) um dort meine Server / LXC Container und Co in einem VLAN zusammen zu fassen. Die Regel um die es geht, ist die in der ich dem Hauptnetzwerk (wo PC und so drin ist) den Zugriff auf den PiHole (Port 53) ermöglichen möchte.

Die Regel Sieht wie folgt aus:

Die IP Gruppe umfasst aktuell nur einen PiHole und die Port Gruppe den Port 53. Die Regel habe ich auch vor den Drop Regeln Positioniert, und auch den Typ habe ich in alle 3 Möglichkeiten (LAN in, LAN out und LAN Local) zum Testen mal gepackt. Aber leider ohne Erfolg. Mein Problem ist, dass ich mit dem PC nicht mehr ins Internet komme, sobald ich als DNS Server den PiHole ausgewählt habe. Wenn ich jedoch den PC ins VLAN "Server Netz" hinzufüge und dort den PiHole rein packe läuft alles wie es soll über den PiHole und ich komme ins Netz.

Vielleicht hat jemand von euch eine Idee?

Diese Regel habe ich in verschiedenen Videos gesehen und auf verschiedenen Seiten im Netz auch wiedergefunden, nur bei mir will diese nicht. Der einzige Unterschied, der mir im großen und ganzen aufgefallen ist, ist das die in der Regel die Dream Maschine Pro oder ein USG mit Docker nutzen. Ich hoffe ich bekomme das auch mit meinem Dreamrouter hin.

Wenn weitere Informationen benötigt werden, nur ein Wort ich verrate was ich kann.

Michael