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

[raspido]

Guten Tag,

ich bin noch recht neu was TP Link Omada angeht. Bislang habe ich die gute Alte Fritz!Box im Einsatz, möchte aber gerne von der umsteigen. Damit ich nicht gleich das aktuell laufende Netzwerk nicht komplett über den Haufen werfe und erstmal etwas Erfahrungen sammeln möchte und einfach das ein oder andere per "Try and Error" einfach testen ohne gleich alles zu "schrotten" habe ich mir ein neue Netzwerkumgebung aufgebaut hinter der Fritz!Box.

Diese besteht aus folgenden Geräten:

• Ein ER605
• Ein TL-SG2008P
• Ein OC200
• Ein Access Point AC1350 / EAP225

Da ich mich vor dem Kauf schon etwas versucht habe schlau zu machen, hab ich etwas bei Youtube rumgestöbert und bin auf eine Art "Anleitung" gestoßen, die meinem geplanten Einsatzsenario sehr nahe kommt und einen vernünftigen Ansatz zu machen scheint.

Ich habe mich fast komplett an das Tut gehalten, lediglich ein paar Kleinigkeiten habe ich abgeändert:

• Das Secruty LAN heißt bei mir einfach LAN mit der SSID HomeNet
• Das IoT Netzwerk heißt bei mir IoTDev mit der SSID IoTDev und liegt im VLAN 20 und nicht im VLAN 107

Nun zu meinem Problem:

Laut Video soll es mit den Security Rules möglich sein vom LAN ein Ping ins IoTDev zu schicken, andersrum aber nicht. Was gleichbedeutent ist, ich kann vom LAN ins IoTDev eingreifen. Die andere Richtung soll aber nicht klappen. Nur leider klappt das so nicht. Also wenn ich mein Laptop (Windows 10) und mein iPhone im gleichen Netzwerk habe, klappt es zu pingen. Wenn mein Laptop im HomeNet ist und mein iPhone im IoTDev ist, klappt es nicht vom Laptop zum Phone zu pingen.

Ich habe zum Testen eine Zweite Regel angelegt, in der ich vom LAN (als Quelle) alle Ports ins IoTDev (als Ziel) frei gebe. Nur das brachte kein Erfolg. Hat da jemand ein Tip für mich, was da gerade schief läuft?

Von den verschiedenen Netzwerken kann ich aber ohne Probleme Google oder ähnliches anpingen.

Bevor ich es vergesse, hier der Link zum YouTube Tut



Michael

 

[Raijin]

Wenn mein Laptop im HomeNet ist und mein iPhone im IoTDev ist, klappt es nicht vom Laptop zum Phone zu pingen.

Bitte grundsätzlich nicht mit einem Smartphone testen. Das ist kein geeignetes Gerät zur Diagnose von Problemen. Es gibt nämlich durchaus auch Szenarien, in denen das Endgerät für die Probleme verantwortlich ist - zB dessen lokale Firewall - und da hat man bei einem Smartphone schlechte Karten. Nutze daher wenn's geht zunächst PCs und Laptops bis die Grundfunktionen der Infrastruktur sichergestellt sind und es mit PC/Laptop so funktioniert wie es funktionieren soll.

Was nun dein konkretes Problem angeht, ist es denkbar unpraktisch, zu erwarten, dass jetzt alle das halbstündige Tutorial durchgucken, um dein Setup zu kennen. Wenn du mit VLANs rumhantierst, solltest du auch in der Lage sein, die relevanten Informationen zu liefern. Das wären zB die IP-Adresse der Geräte bzw deren Schnittstellen, die VLAN-Konfiguration des Switches und der APs sowie die betreffenden ACL/Firewalls. Zumindest einige dieser Infos solltest du zum drüberlesen zur Verfügung stellen. Nicht selten fällt einem bei der Zusammenfassung selbst der Fehler auf.

Zur weiteren Diagnose kannst du dich mal in der Bedienungsanleitung anschauen welche Diagnosefunktionen der ER605 bietet. Normalerweise ist mindestens ein Paket capture dabei. Mit Hilfe dieses Werkzeugs kann man mitschneiden ob der Ping vom PC in Netz A auf den PC in Netz B überhaupt an der A-Schnittstelle des Routers ankommt. Wenn ja, kann man im nächsten Schritt prüfen ob der Ping an der B-Schnittstelle rausgeht und die Antwort den gleichen Weg zurück nimmt. So verfolgt den Ping bis man die Stelle findet, an der er einfach aufhört - da ist der Fehler zu suchen. Bleibt zB die Antwort des Ziels schon am Router aus, hat das Ziel offenbar gar nicht geantwortet, mutmaßlich weil dessen Firewall geblockt hat.

 

[raspido]

Guten Morgen,

okay, fangen wir erstmal mit meinen eingestellten Parameter der Geräte an.

Der Router hat die IP Adresse 192.168.0.1
Der Controller hat die IP Adresse 192.168.0.5
Der Accesspoint hat die IP Adresse 192.168.0.10
Der Switch hat die IP Adresse 192.168.0.20

jeweils mit einer Statischen Adresse.

Der Router ist an Port 1 mit dem bestehenden Netzwerk verbunden, welches das Internet zur verfügung stellt für Updates und ähnliches. An Port 4 des Routers ist der Switch mit Port 8 verbunden. Der PC (IP Adresse 192.168.0.50) ist an Port 7 des Switches verbunden. Der Controller an Port 1, sowie der Accesspoint an Port 2, da der Switch POE lediglich an Port 1-4 zur verfügung stellt.

Es geht insgesamt 3 Netzwerke (LANs) mit entsprechender VLAN ID.

Das ist zum einen Das Gastnetzwerk mit dem Subnetz / Gateway 192.168.10.1/24 in VLAN 10, dazu kommt das IoTDev Netzwerk mit dem Subnetz / Gateway 192.168.20.1/24 in VLAN 20 und das LAN Netzwerk mit dem Subnetz / Gateway 192.168.0.1/24 im VLAN 1.

Den VLANs habe ich 3 SSIDs zugewiesen. Das ist zum einen Das HomeNet im VLAN 1, das Gast als Gastnetzwerk (mit Parameter Gastnetzwerk) in VLAN 10 und das WLAN IoTDev im VLAN 20.

Einstellungen im Switch habe ich keine konkreten vorgenommen. Zumindest nicht direkt am Gerät über die Oberfläche. Der Port 8 des Switches, welcher mit dem Router verbunden ist, hat bei der Konfiguration des Ports bei Profile "All" ausgewählt. Und somit wenn ich das bislang richtig verstehe, ist somit der Port für alle VLANs offen oder? Bei den anderen Ports steht bei den Profilen auch ALL drin, was ich gerade nochmal nachgesehen habe. Trotz allem ist mein PC im LAN (VLAN 1) gelandet, was auch so gewünscht ist.

Als Switch-ACL habe ich folgendes Eingerichtet:

Name: BlockIOT
Als Policy habe ich Deny für alle Protokolle ausgewählt
Als Source Netzwerk habe ich das IoTDev ausgewählt und als Destination das Netzwerk LAN

Zusätzlich habe ich Testweise eine zweite Swich-ACL eingebunden mit folgenden Einstellungen:
Name LAN to IoT
Policy Permit aller Protokolle
Als Source Netzwerk habe ich das LAN Netzwerk angegeben und als Destination das IoTDev Netzwerk.

Diese Regel habe ich aber aktuell wieder deaktiviert, da diese beim Testen kein Erfolg gebracht hatte.

Zum Testen habe ich mir zum Laptop noch ein Desktop PC in Betrieb genommen, aber leider nicht mit mehr Erfolg. Den Laptop nutze ich primär dafür, in die verschiedenen WLANs / Netzwerke zu kommen um Pings zu senden / empfangen. Da der PC mittels LAN Kabel verbunden ist, habe ich den einfach in das LAN Netzwerk gepackt.

Ich hoffe diese Informationen helfen so schon weiter, einzublicken, wo bei mir der Schuh drückt. Die einzigen Unterschiede zum Video ist, dass das IoT Netzwerk IoTDev heißt und im VLAN 20 statt 107 hängt und ich den Hardwaregeräten eine Feste IP zugewiesen habe, also nicht mehr per DHCP um so diese im unteren IP Bereich zu haben. Wo ich hoffe, dass das nicht zu irgendwelchen Problemen führt?


Michael

Ergänzung (20. Oktober 2022)

Ich habe gerade etwas weiter rum getestet, um zu gucken was passiert. Da habe ich am Switch den Port 6 auf Profil "Gast" gestellt und mich dann mit einem LAN Kabel an den Port gehängt. Wie zu erwarten war habe ich eine IP aus dem 192.168.10.0 Bereich bekommen. Nur der Zugriff auf den Controller der die IP Adresse 192.168.0.5 war trotzdem möglich.

Ist ein anderes "Problem", was auch eher im Hintergrund steht, da ich eigentlich keine LAN Geräte als "Gast" haben werde. Aber mein Laptop, im Gast WLAN angemeldet hat wie gewünscht kein Zugriff auf den Controller.

Wollte diese Information trotzdem mal gegeben haben.

 

[Raijin]

Ich denke da hakt es noch an der generellen Konfiguration.

Zunächst ein paar Erläuterungen:

LAN-Ports können in zwei Modi betrieben werden, als Access Port und als Trunk Port. Access Ports definieren sich dadurch, dass sie fest einem VLAN zugeordnet sind, untagged wie es so schön heißt. Das angeschlosse Gerät hat also keinerlei Kenntnis von der Existenz der VLAN-IDs.
Dem entgegen stehen die Trunk Ports. Diese werden mit allen oder den gewünschten VLANs als tagged konfiguriert. Dabei werden alle Pakete, die diesen Port verlassen mit einem VLAN-Tag versehen, der jeweiligen VLAN-ID.

Access Ports sind daher für den Anschluss von Endgeräten, während Trunk Ports für die Weiterverteilung der VLANs zuständig sind, zB zu einem Access Point, der zu jeder ID eine SSID erstellt, oder eben zu einem weiteren Switch, der seinerseits weiterverteilt oder mittels Access Ports Endgeräte versorgt.

"All" wird für einen Trunk Port stehen, der alle VLAN-IDs enthält, auch jene, die an dem Port womöglich gar nicht benötigt werden.
"Gast" wird mutmaßlich für einen Access Port im Gast-VLAN sein, also untagged.

Switch-ACL sind eine Art Firewall auf L3-Switches, die beim Inter-VLAN-Routing, also dem direkten routen/switchen von einem Switch-Port in VLAN 10 zum anderen Switch-Port in VLAN 20, die Zugriffe reglementieren. Das kommt aber eher in professionellen Netzwerken mit Layer3-Switches und viel Traffic zwischen den VLANs zum Tragen. In Heimnetzwerken mit VLANs routet man in der Regel durch den Router und dessen Firewall reglementiert die Zugriffe.



In deinem Fall scheint es mir so, dass das Setup nicht sinnvoll strukturiert ist und deswegen Verbindungen nicht funktionieren, obwohl sie funktionieren sollten und andersherum.

Beschäftige dich zunächst einmal mit der Materie und klicke nicht blind und ohne zu wissen was du da tust einfach irgendwelche Tutorials nach. Nicht selten ist das dort dargestellte Szenario eben nicht 1:1 übertragbar oder es fehlen bestimmte Details. Wenn du dir schon nicht sicher bist wie die Ports am Switch zu konfigurieren sind, scheinst du nicht nachvollziehen zu können was da passiert bzw passieren soll.

Bei Thomas Krenn gibt es ein sehr anschauliches Beispiel für VLANs, um das Konzept besser zu verstehen. VLAN-Grundlagen

 

[raspido]

Zu dem Punkt mit der Konfiguration der Ports am Switch bin ich mir sicher, dass diese aktuell alle auf ALL sind. Dies werd ich gleich mal entsprechend anpassen. So dass die Ports des Controller und des PC das Profil LAN bekommen. Bei den Ports vom Router und vom AP kann ich ALL lassen, da diese ja Zugriff zu allen VLANs haben sollen. An sich ist ein gewisses Grundverständnis da, also ist nicht dass ich bei Adam und Eva anfange.

Aber ich werd mir das gleich mal angucken, was du gepostet hast. Das Videotutorial habe ich eher als "Grundlage" genommen, da der eigentlich einen Eindruck machte, das er versteht was er tut. Ich nutze an sich schon gerne wenn vorhanden ist um ein Einstieg in was "neuem" zu ermöglichen.

Vor allem wenn man was "neues" bzw. was anderes macht, ist ja auch wichtig gewisse Erfolgserlebnisse zu haben und da hat mir in der Vergangenheit solche Videos immer gut geholfen.

Nur werde ich da dann nochmal bisschen weiter gucken müssen, wie ich mein Problem in den Griff bekomme.

Und naja zur Hardwareauswahl, habe ich diese getroffen, da diese in meinem Netzwerk später so gut zum Tragen kommen können und für den Einstieg "erschwinglich" sein sollte. Ich habe mein Haus Netzwerktechnisch mit 2 Netzwerkschränken ausgestattet und die aktuelle Hardware (in erster Linie der Switch und der AP) sollen im "Labor" oder Bastelumgebung zum Einsatz kommen. Die Verbindung zum Hausnetzwerkschrank habe ich in einem Duplexkabel ausgeführt. Der 2te Netzwerkschrank ist zum Teil eher etwas "Spielerei", aber ich wollte so die Möglichkeit haben, wenn ich verschiedene Dinge teste (eigen gebaute IoT Geräte basiernd auf Wemos D1 Mini und ähnlichem bzw. Raspberry Pi), die Netzwerkkonfiguration anpassen kann, ohne gleich jedes mal in den Keller rennen zu müssen um z.B. Netzwerkdosen neu zu Patchen oder ähnliches. Also das wollte ich nur zusätzlich mal als Hintergrundinfos geben, auch wenn das mit dem aktuellen Problem noch kein Fortschritt bringt.

Allgemein zur Verbindung habe ich die Ports am Switch so genutzt um die PoE Ports für Geräte frei zu halten, die PoE können.

 

[raspido]

@Raijin die von dir erwähnte Seite habe ich mir gerade mal näher angeguck. Bis zu dem Punkt war mir das soweit klar gewesen. Mein Aktuelles Problem ist glaub ich eher ein Problem was aus der "Richtung" Firewall oder vom Router kommt. Aber ich denke irgendwie werde ich das noch weiter raus bekommen.

 

[raspido]

Das wären meine Aktuellen Einstellungen im Bereich ACLs:

Also wollte es zumindest mal zeigen, was ich eingestellt habe und was möglich ist für die, die Omada nicht kennen.

 

[Bob.Dig]

Uih, leugnen kann er auch... top aktuell sag ich da. 😉

 

[Raijin]

Nur mal so: Im Screenshot ist die Regel NICHT aktiviert.

Ergänzung (20. Oktober 2022)

Uih, leugnen kann er auch... top aktuell sag ich da. 😉

Jo, das ist echt eine grandiose Übersetzung...

 

[Bob.Dig]

Jo, das ist echt eine grandiose Übersetzung...

Tatsächlich der erste Treffer bei DeepL: verleugnen = deny
Also bei sowas würde ich mir keine, derart schlechte deutsche Übersetzung geben.

 

[raspido]

Guten Abend,

das die Regel beim Screenshot abgeschalten war, ist mir klar. Ich hab die danach wieder aktiviert.

Hatte die nur temporär deaktiviert um zu gucken ob die Kommunikation überhaupt funktioniert. Ich dachte man arbeitet sich schrittweise ans Problem heran um das Ziel zu erreichen.

 

[Raijin]

Hm.. Also meine Vermutung ist, dass es grundsätzlich an der ACL liegt. Im Video wird ein anderer Switch verwendet. ACLs auf einem Switch sind eine Art Firewall, die in einem (VLAN-)Switch integriert ist. Dazu muss der Switch das aber auch tatsächlich unterstützen und deutlich mehr Layer3-Funktionalität bieten als es bei den meisten "Layer2+" Switches der Fall ist. Die meisten (günstigeren) VLAN-Switches unterstützen nämlich lediglich 802.1Q, also VLAN-Tags an sich, aber kein Routing, keine ACLs, kein DHCP-Server, nix. Layer3-Switches sind vom Funktionsumfang hingegen beinahe vollständige Router.

ACLs in einem Switch sind auch eher für große Netzwerke relevant wo viele VLANs und viele Clients zum Einsatz kommen und das vollständige Routen über den Uplink zum Router zur Überlastung führen könnte. In einem Heimnetzwerk ist das aber vernachlässigbar und ich würde den Switch Switch sein lassen und die Zugriffskontrolle über den Router in dessen Firewall regeln.

Im Video sieht man nur wie die ACL-Regel erstellt wird, aber ich bin mir nicht sicher ob man diese noch auf den Switch ausrollen muss. Auch konnte ich beim Durchzappen nicht sehen wo die Ports des Switches konfiguriert werden. Eventuell fehlen hier wichtige Details.


Viel mehr kann ich dazu mangels Praxis mit dem Omada-System und dessen Controller leider nicht sagen. Schau dir sonst noch ein paar andere Videos an ob dort das eine oder andere Detail anders behandelt wird und etwaige Fehler aufzeigt.

 

[raspido]

Okay, muss ich nochmal gucken, vielleicht setze ich auch alle Geräte nochmal auf Werkseinstellung zurück oder so und fange sogesehen bei 0 an. Also schaden tut es nicht.

Ich hab mir mal bei TP Link beide Router in ein Vergleich angeguckt und zumindest auf den ersten Eindruck unterstützen beide Switche einige an Protokollen und so. Wobei der Unterschied zumindest für mich auf dem ersten eindruck eher "minimal" wirkt.

Hier mal der Link zum Vergleich: Link zum Produktvergleich bei TP Link

Ich weiß, manchmal kann das "minimale" schon eine große Auswirkung haben.

Aber ich spiele mit dem Gedanken vielleicht mir den anderen Switch noch zu organisieren. Eine Summe von rund 170€ ist nicht nichts, aber falls es tatsächlich an meinem Switch liegt, wäre es natürlich mehr als ärgerlich. Und normal denke ich kann man solche Geräte auch noch gut weiter verkaufen bzw. vielleicht noch in Retoure geben.

Aber vielleicht hat jemand Zeit und Lust mal bei dem Link über die Daten zu gucken. Wie gesagt ich selber habe auf dem ersten Blick kein wesentliche Unterschiede im Funktionsumfang gesehen.

Michael

PS: Was mich vor allem etwas "wundert" ist, sobald ich die ACLs deaktiviere kann ich vom Hauptnetzwerk aufs IoT Netzwerk zugreifen und umgekehrt. Also vermute ich fast, dass da noch igendwo der Hund begraben ist. Aber erstmal danke bis hier hin für eure Hilfe und Tipps / Denkanstöße

 

[raspido]

Auf Werkseinstellungen setzen und von 0 anfangen war leider auch nicht von Erfolg gekrönt.

Eigentlich gibt es direkt 3 Möglichkeiten woran es scheitert

1. Es fehlt was in der Konfiguration.
2. Die minimalen unterschiede bei dem Switch sind ggf. doch wichtiger als gedacht.
3. Was man ungern zugeben möchte, aber man nicht ausschließen kann. Ich habe bei dem Neuerstellen wieder einen Fehler begangen.

Etwas frustrierend ist das gerade. Aber naja Augen zu und durch. Bzw. aufgeben bis es läuft ist eigentlich keine Option für mich.

Wie gesagt, vielleicht kann ja jemand gucken ob die "unterschiede" ggf. den Ausschlag bringen können was die Funktionen der Switche angeht.

 

[raspido]

Moin,

eine Frage fällt mir gerade noch ein. Bzw. ist mir die Nacht noch gekommen. Kann auch allein schon die Version einen massiven Ausschlag geben ob das Funktioniert oder nicht? Weil ich hab gerade auf mein Switch geguckt und gesehen, dass das Gerät die Version 1.0 hat und die letzte Version dieses Gerätes die Version 3.0 ist?

Michael

 

[DiedMatrix]

Logisch kann das sein, erst Recht wenn du noch mit der ERSTEN Version unterwegs bist, die ja selten Bugfrei ist. Dann Update mal ALLE Komponenten

 

[raspido]

Ich meinte mit Version nicht die Software Version sonder die Geräte Version.

Softwaremäßig sind alle auf dem aktuellen Stand.

 

[raspido]

Hey Leute,

ich dachte ich bringe euch mal auf den aktuellen Stand der Dinge.

Ich habe heute den anderen Switch (TL-SG2210MP [Der aus dem Video, womit alles angefangen hat]) bekommen und naja irgendwie ist das ganze fast eher schlimmer geworden und nicht besser

Ich habe erstmal alle Geräte mittels Resettaster zurück gesetzt um wirklich bei 0 zu beginnen mit dem neuen Switch. Habe dann erst den Einrichtungsassistenten vom Controller durchgeklickt, dann wie gewohnt die VLANs und WLANs erzeugt. Im Anschluß mein Wemos D1 Mini (Webserver) in Betrieb gesetzt, geguckt ob ich per PC drauf zugreifen kann und das funktionierte. Dann habe ich im Anschluß die "Problemzone" ACL eingerichtet und nichts ging mehr. Diese wieder deaktiviert und nochmal versucht den Webserver zu erreichen und nunja, nichts geht mehr.

Habe dann aus lauter Verzeiflung mal in die Geräte geguckt und plötzlich stand beim Router (ER605) "ADOPTING", obwohl ich vorher schon alle Geräte "Adoptiert" habe und alle als Connected drin standen. Ich habe mir nichts groß gedacht, Resete ich den Router nochmal und adoptiere den noch mal. Das ging auch, aber kurz danach wieder Stress beim Router.

Irgendwie habe ich das Gefühl, als ob der Router ein hat. Oder hat jemand sowas schon mal erlebt bzw. wie wären eure Vermutung bei so einem Verhalten?

Wollte es morgen nochmal mit dem ersten Switch testen. Nur so langsam wird die Verzweiflung (mit Haare raufen und graue Haare bekommen) immer etwas größer.


Michael

PS: Ist das mit den Geräten von Unify ähnlich schlimm? Oder hat da auch noch weniger jemand groß Erfahrung. Bin zwischendruch am überlegen, alles wieder einzupacken und back to Amazon und was anderes zu kaufen.

 

[DiedMatrix]

Melde dich doch mal bei TP-Link Support. Hab mal gehört die sollen nicht schlecht sein (im Gegensatz zu Ubiquiti)

 

[raspido]

Bei denen über den Live Chat wollte ich es ständig versuchen, nur jedesmal kam "Unsere Mitarbeiter sind derzeit nicht erreichbar."

Werde es aber morgen mal zur Not per Telefon testen. Nur was mich aktuell etwas nervt ist, dass der Router nach kurzer Zeit "raus fliegt" und ich den neu adoptieren muss. Werde morgen nochmal alles mit dem alten Switch verbinden und ersteinrichten und dann gucke ich mal weiter ob er auch wieder ständig raus fliegt. Weil von der Hardware wäre mir der "alte" Switch lieber, der neue passt nicht in meinen Netzwerkschrank (ist ein 10 Zoll Schrank aus meinem Fundus und der passt bei dem Bereich perfekt hin)


Michael