18
Funktioniert VLAN via 802.1x auch mit unmanged Switchen?
Hallo,
funktioniert die VLAN-Zuweisung mittels 802.1x auch wenn da ein unmanaged Switch zwischenhängt?
Bei einem Kunden stehen in mehreren Räumen Yealink-Telefone und verschiedene Personen stecken Ihr Notebook nun in den internen Switch dieser Telefone. Denn es sind zuwenige Anschlüsse vorhanden.
Danke
Stefan
funktioniert die VLAN-Zuweisung mittels 802.1x auch wenn da ein unmanaged Switch zwischenhängt?
Bei einem Kunden stehen in mehreren Räumen Yealink-Telefone und verschiedene Personen stecken Ihr Notebook nun in den internen Switch dieser Telefone. Denn es sind zuwenige Anschlüsse vorhanden.
Danke
Stefan
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6530728267
Url: https://administrator.de/forum/funktioniert-vlan-via-802-1x-auch-mit-unmanged-switchen-6530728267.html
Ausgedruckt am: 29.03.2025 um 11:03 Uhr
18 Kommentare
Neuester Kommentar
Kurze Antwort: Nein
Etwas ausführliche. Du könntest einen Hub testen, hab ich zwar noch nicht selber versucht, aber theoretisch könnte das gehen. Aber jeder Client muss dann so eingestellt werden, dass er mit dem Tagged Paket klar kommt, du kannst dann keine untagged Pakete auf die Reise schicken.
Ein HUB ist kein Switch verwechsel das nicht. Ein Hub sendet egal was rein kommt an jeden beliebigen anderen Port wieder raus.
Es gibt aber auch kleine Switche wie z.B. Cisco SG250-08 G
Etwas ausführliche. Du könntest einen Hub testen, hab ich zwar noch nicht selber versucht, aber theoretisch könnte das gehen. Aber jeder Client muss dann so eingestellt werden, dass er mit dem Tagged Paket klar kommt, du kannst dann keine untagged Pakete auf die Reise schicken.
Ein HUB ist kein Switch verwechsel das nicht. Ein Hub sendet egal was rein kommt an jeden beliebigen anderen Port wieder raus.
Es gibt aber auch kleine Switche wie z.B. Cisco SG250-08 G
Es gab/gibt Switches die einfach Pakete forwarden die die Bytes belegt haben.
Sowas will man aber nicht im Netz haben als Hardware.
Als Softswitch zum hacken/debuggen sieht man das eher, aber dann in Händen von Wissenden.
Sowas will man aber nicht im Netz haben als Hardware.
Als Softswitch zum hacken/debuggen sieht man das eher, aber dann in Händen von Wissenden.
@2423392070
Sicher das das Switche waren? Mich würd mal interessieren was es da so gibt, weist du noch was das für ein Modell war?
Sicher das das Switche waren? Mich würd mal interessieren was es da so gibt, weist du noch was das für ein Modell war?
Modell kann ich dir nicht mehr sagen.
Ich hatte diesbezüglich früher AT Switches.
Das war früher Mal normal, fast Standard, dass Switches das weitergeleitetet haben. Die Switches sahen das aber als Nutzlast.
Ich hatte diesbezüglich früher AT Switches.
Das war früher Mal normal, fast Standard, dass Switches das weitergeleitetet haben. Die Switches sahen das aber als Nutzlast.
Moin,
der interne Switch von Yealink-Telefonen ist managebar. Du kannst einstellen, das Telefonie über VLAN 1 und der zusätzliche Switchport über VLAN 2 geht. Mußt dann am zentralen Switch und Router halt nur die VLANs richtig auf den Ports einstellen.
cu,
ipzipzap
der interne Switch von Yealink-Telefonen ist managebar. Du kannst einstellen, das Telefonie über VLAN 1 und der zusätzliche Switchport über VLAN 2 geht. Mußt dann am zentralen Switch und Router halt nur die VLANs richtig auf den Ports einstellen.
cu,
ipzipzap
Ja das funktioniert wenn die Switches dahinter Mac based VLANs als Feature supporten!
802.1x erledigt bekanntlich die Authentifizierung eines Gerätes über einen Authenticator (meist)-Switch, der über die Kommunikation mit dem Radius entscheidet, ob das Gerät überhaupt ins Netz darf. Die dynamische VLAN-Zuweisung ist nur ein Nebenprodukt.
Einem dazwischen liegenden unmanaged Switch sind dabei sowohl die Authentifizierungspakete zwischen Radius und Authenticator, als auch das zugewiesene VLAN völlig egal. Die Authentifizierungsinformationen sind für ihn normaler Traffic. Er kann zudem weder taggen, noch Tags verstehen, entfernt aber auch kein Tag. Und natürlich kann er nicht selbst Authenticator sein. Der Schutz des Netzes ist an dieser Stelle also aufgebrochen, aber der ist bei klassischem .1x ohnehin eher gering. Wie der Kollege @aqui zutreffend schreibt, muss dann an einem weiteren Switch/Gerät die Authentifizierung erledigt bzw., wenn VLANs zugewiesen werden, diese verstanden werden.
Für das beschriebene Umfeld brauchst Du doch aber auch kein VLAN. Das Telefon agiert wie ein normaler Switch, dem PC ist völlig egal, ob er am Telefon hängt oder direkt im Netz. Nur nicht mehr, wenn das Yealink sich aufhängt
Und in einer Butze, die solche Switche verwendet, gibt es sicher keine technischen Gründe, die Netze zu trennen. Ob es zu den TOM der DSGVO gehört, ist ungeklärt, aber eher zweifelhaft.
Viele Grüße, commodity
Einem dazwischen liegenden unmanaged Switch sind dabei sowohl die Authentifizierungspakete zwischen Radius und Authenticator, als auch das zugewiesene VLAN völlig egal. Die Authentifizierungsinformationen sind für ihn normaler Traffic. Er kann zudem weder taggen, noch Tags verstehen, entfernt aber auch kein Tag. Und natürlich kann er nicht selbst Authenticator sein. Der Schutz des Netzes ist an dieser Stelle also aufgebrochen, aber der ist bei klassischem .1x ohnehin eher gering. Wie der Kollege @aqui zutreffend schreibt, muss dann an einem weiteren Switch/Gerät die Authentifizierung erledigt bzw., wenn VLANs zugewiesen werden, diese verstanden werden.
Für das beschriebene Umfeld brauchst Du doch aber auch kein VLAN. Das Telefon agiert wie ein normaler Switch, dem PC ist völlig egal, ob er am Telefon hängt oder direkt im Netz. Nur nicht mehr, wenn das Yealink sich aufhängt
Und in einer Butze, die solche Switche verwendet, gibt es sicher keine technischen Gründe, die Netze zu trennen. Ob es zu den TOM der DSGVO gehört, ist ungeklärt, aber eher zweifelhaft.Viele Grüße, commodity
sind dabei sowohl die Authentifizierungspakete zwischen Radius und Authenticator, als auch das zugewiesene VLAN völlig egal.
Da muss man etwas vorsichtig sein. Nicht alle unmanaged Switches forwarden EAPoL Pakete. Hier ist zur Sicherheit immer der Wireshark gefragt um das wasserdicht zu verifizieren. aber der ist bei klassischem .1x ohnehin eher gering
Eine kühne Behauptung und sachlich so nicht richtig, denn du hast hier sehr wahrscheinlich etwas missverstanden.802.1x ist eine zentrale Sicherheitsfunktion um Zugriffe auf ein LAN oder WLAN sicher und wasserdicht zu authentisieren. Das ist keineswegs unsicher sondern ein etabliertes Verfahren eben weil es sehr sicher ist.
Möglich das du es hier im Eifer des Gefechts mit Mac Bypass verwechselst, was die Authentisierung rein auf Basis von Mac Adressen macht. Beide Verfahren sind aber unterschiedlich und auch koppelbar und sollte man deshalb nicht in einen Topf schmeissen.
Um zur Frage des TOs zurückzukommen ist das auf mehrfache Art und Weise zu lösen bei entsprechender Switch HW.
- Viele embeddete Telefonswitches sind heutzutagen mit einem .1x Client ausgerüstet, supporten also von sich aus schon .1x
- Mit einem unmanaged Switch davor muss der der dahinter authentisierende Switch .1x multiple Mac Port Authentication supporten. Wird auch oft als "Client based VLANs" bezeichnet. Hier authentisiert der Switch dann auch mehrfache Clients an einem Port. Supportet er das nicht, ist ein kaskadierter unmanaged Switch unsinnig, denn dann kann dort ja immer nur ein einziges Endgerät angeschlossen werden.
- Viele einfache Switches supporten die Authentisierung multipler Endgeräte an einem solchen Port oft nur mit Mac Bypass also nur per Mac und nicht mit .1x. (sog. Mac based VLANs). Damit ist eine .1x basierte Mehrfachauthentisierung dann auch ausgeschlossen. Hier hilft immer der genaue Blick ins Datenblatt!
Das Telefon agiert wie ein normaler Switch, dem PC ist völlig egal
Das ist nicht so wenn das Telefon eine 802.1p QoS Priorisierung nutzt. .1p erzwingt immer ein 802.1q VLAN Tag weil es Teil des .1q Headers ist.Damit ist ein Voice VLAN immer zwingend vorgegeben. Der Voice Traffic ist dann immer tagged aber den PC dahinter will man natürlich nicht im Voice VLAN haben. Folglich muss dann also entweder eine dynamische VLAN Zuweisung des UNtagged Traffics an dem Port passieren oder man macht die VLAN Zuweisung statisch oder lässt sie per LLDP negotiaten. Das können heute fast alle Switches.
So ein Setup ist also immer zwingend davon abhängig ob man eine Layer 2 QoS Priorisierung (802.1p) oder eine Layer 3 QoS Priorisierung (DSCP) in seinem LAN fährt und mit LLDP Voice VLAN Funktion arbeitet! Kollege Kittel macht dazu aber keine oder nur sehr oberflächliche Angaben. Deshalb ist die Geschichte also nicht ganz so trivial! 😉
Warum sollte ein (noch dazu) "dummer" L2-Switch sich um Pakete eines höheren Layers kümmern? Ich glaube Dir das natürlich, technisch schlüssig erscheint es mir aber nicht.
Einfach das Kabel eines autorisierten Gerätes rausziehen, Switch dazwischen und - wie sagte Bobbele seinerzeit: Bin ich schon drin?
Klar: Die neuen Implementierungen können das abfangen, aber z.B. Mikrotik hat MACsec erst unlängst (ROS 7.6) hoffentlich funktionsfähig eingeführt und es ist immer noch nicht offiziell dokumentiert. Und ich denke, dass so mancher Billigheimer da auch noch nachhängt, außen aber .1x draufschreibt. Da könnte ich mich natürlich irren.
Viele Grüße, commodity
Eine kühne Behauptung und sachlich so nicht richtig, denn du hast hier sehr wahrscheinlich etwas missverstanden.
Die Behauptung war, zugegeben, ein bisschen kühn, ist aber weder nrichtig noch habe ich, so denke ich, etwas missverstanden. Im Gegenteil: Wir hatten das Thema bereits mal zusammen mit @colinardo am Wickel. 802.1x ist ohne MACsec so leicht auszuhebeln, dass meine Oma das könnte, wenn ich noch eine hätte. Das meinte ich (vielleicht missverständlich) mit "klassischem" .1x. https://de.wikipedia.org/wiki/IEEE_802.1X#Sicherheitsl%C3%BCcken_in_802. ...Einfach das Kabel eines autorisierten Gerätes rausziehen, Switch dazwischen und - wie sagte Bobbele seinerzeit: Bin ich schon drin?
Klar: Die neuen Implementierungen können das abfangen, aber z.B. Mikrotik hat MACsec erst unlängst (ROS 7.6) hoffentlich funktionsfähig eingeführt und es ist immer noch nicht offiziell dokumentiert. Und ich denke, dass so mancher Billigheimer da auch noch nachhängt, außen aber .1x draufschreibt. Da könnte ich mich natürlich irren.
Viele Grüße, commodity
802.1x ist ohne MACsec so leicht auszuhebeln
Vermutlich missverstehst du es immer noch. 802.1x hat nichts mit Mac Adressen und einer Authentisierung mit Mac Adressen zu tun. Mac Adressen spielen hier keinerlei Rolle. In sofern greift auch das Argument Unsicherheit nicht mehr.802.1x authentisiert immer mit Username Passwort aus einem AD oder mit Zertifikaten! Die Kommunikation passiert dabei verschlüsselt über EAPoL. Guckst du auch hier.
Wie du z.B. die Königsklasse mit Zertifikaten "leicht" aushebeln willst dürfte dann eine sehr spannende Lektüre für das gesamte Forum und die Netzwerksicherheit an sich werden. 😉
Einfach das Kabel eines autorisierten Gerätes rausziehen, Switch dazwischen und
Das nützt dir bei 802.1x gar nichts. Damit wirst du einen .1x authentisierenden Uplink Port nicht überlisten können. 802.1x mit zyklischem Reauthentisierungs Intervall schonmal gar nicht.Mac Bypass vielleicht, weil man an die Mac Adresse rankommt und die klonen kann. Es geht hier aber um .1x und eben nicht um MBP!
Dein Kardinalsfehler ist das du 802.1x irgendwie immer mit Mac Adressen assoziierst was aber technisch falsch ist. Ganz andere Baustelle!
Ich weiß, wie 802.1x funktioniert und habe es auch schon eingerichtet. Ich habe hier auch überhaupt nichts von MAC-Adressen geschrieben. Keine Ahnung, wo Du das rausliest. Das Problem ist einfach, dass der ursprüngliche .1x-Standard den Port öffnet, wenn nur ein Gerät authentifiziert ist.
Lies gern, was ich dazu verlinkt habe. Oder was Du selbst dazu geschrieben hast.
Oder die ROS Doku dazu (ich habe es für Dich fett gemacht):
Interessant fände ich noch eine Erklärung hierzu:
Lies gern, was ich dazu verlinkt habe. Oder was Du selbst dazu geschrieben hast.
Oder die ROS Doku dazu (ich habe es für Dich fett gemacht):
A RouterOS dot1x server acts as an authenticator. An interface where dot1x server is enabled will block all traffic except for EAPOL packets which is used for the authentication. After client is successfully authenticated, the interface will accept all received traffic on the port. If the interface is connected to a shared medium with multiple hosts, the traffic will be accepted from all hosts when at least one client is successfully authenticated. However, it is possible to configure dynamic switch rules to accept only the authenticated user source MAC address and drop all other source MAC addresses. In case of failed authentication, it is possible to accept the traffic with a dedicated port VLAN ID.
Wie man auch bei Wikipedia lesen kann, ist das der ursprüngliche (von mir als klassisch) bezeichnete Standard. Bessere Hersteller haben nachgelegt. Wenn aber nicht einmal Mikrotik, dann bestimmt nicht alle. Ich hab noch einen managed TP-Link da, vielleicht teste ich den mal die Tage.Interessant fände ich noch eine Erklärung hierzu:
Nicht alle unmanaged Switches forwarden EAPoL Pakete.
Viele Grüße, commodityDas Problem ist einfach, dass der ursprüngliche .1x-Standard den Port öffnet, wenn nur ein Gerät authentifiziert ist.
OK, da haben wir dann aneinander vorbeigeredet, sorry. Das stimmt natürlich nur dann wenn der Switch keine Multi Client Authentication supportet. Das machen aber nur noch einige Billigswitches so. Die meisten unterbinden das mit einer entsprechenden Konfig.Mit Cisco, Ruckus und Co. und dem Flexible Authentication Feature an solchen Ports kann man das wasserdicht unterbinden.
Und was wird wohl in dem Setup, das der Kollege Stefan im ersten Post beschreibt stehen?
Ein ewiges Problem (auch) dieses Forums: Es gibt in der IT mehrere Welten. Die der Konzerne, der Mittelständler, der Kleinunternehmer und der Privaten. Natürlich denkt der Konzern-ITler, der Kollege @2423392070 ist da ein hübsches Beispiel, er hat die Weisheit gepachtet und (nur) so wie es bei ihm läuft ist es richtig. So ist es aber tatsächlich nicht, denn für andere Welten gelten andere Gesetze (und sein Beitrag in diesem Thread war auch, gelinde gesagt, unverständlich).
Das mag ich Deinen Beiträgen: Du denkst in hochqualifizierten Welten, kommst aber (notfalls mal mit einem kleinen Schubs) auch wieder in die Welt der Sterblichen und rückst die Dinge zurecht.
Jetzt würde ich aber immer noch gern verstehen, wie der unmanaged Switch auf seinem Layer das EAPoL rausfiltert.
Viele Grüße, commodity
Ein ewiges Problem (auch) dieses Forums: Es gibt in der IT mehrere Welten. Die der Konzerne, der Mittelständler, der Kleinunternehmer und der Privaten. Natürlich denkt der Konzern-ITler, der Kollege @2423392070 ist da ein hübsches Beispiel, er hat die Weisheit gepachtet und (nur) so wie es bei ihm läuft ist es richtig. So ist es aber tatsächlich nicht, denn für andere Welten gelten andere Gesetze (und sein Beitrag in diesem Thread war auch, gelinde gesagt, unverständlich).
Das mag ich Deinen Beiträgen: Du denkst in hochqualifizierten Welten, kommst aber (notfalls mal mit einem kleinen Schubs) auch wieder in die Welt der Sterblichen und rückst die Dinge zurecht.
Jetzt würde ich aber immer noch gern verstehen, wie der unmanaged Switch auf seinem Layer das EAPoL rausfiltert.
Viele Grüße, commodity
[Von Moderation entfernt.Bitte höflich bleiben!]Ist das wirklich so schwer zu verstehen, dass ein Switch oder Hub, wenn es vom VLAN Tags nichts weiß und der Gesamtrahmen nicht zu groß ist, TPID und TCI als Nutzlast einfach weiterleitet? Das hat sogar jemand in die Spezifikation geschrieben.
Halbwegs moderne Switches machen das nicht ohne explizite Anweisung, weil man so sonst einen VLAN Hopper hätte auf Hardware Basis.
Auch nicht zu verstehen?
[Von Moderation entfernt.Bitte höflich bleiben!]
1
Das macht er wie z.B. einige unmanaged die auch keine Frames mit VLAN Tags forwarden. Das ist eine Frage was die Hersteller da an Asics reinpacken und wie die arbeiten. Das macht der ein so der andere so. Regeln und Standards gibts da in dem Segment nicht. Deshalb ist es bei solchen "sterblichen" Setups mit Frickellösungen immer sinnvoll mit dem Kabelhai mal nachzusehen um sich keinen Wolf zu suchen! 😉
Ok, danke Dir. Bislang hat bei mir alles, was unmanaged Switch war, auch Tags durchgelassen. Erschien mir auch logisch. Aber die Tücke steckt wie immer im Detail.
Kollege @2423392070: Ich habe noch nie einen wirklich kompetenten Menschen erlebt, der es nötig hatte zu beleidigen. Hoffentlich ein Zufall. Ansonsten ergibt sich aus der aus Deinen Äußerungen folgenden Ungleichung eine wenig schmeichelhafte Schlussfolgerung.
Viele Grüße, commodity
Kollege @2423392070: Ich habe noch nie einen wirklich kompetenten Menschen erlebt, der es nötig hatte zu beleidigen. Hoffentlich ein Zufall. Ansonsten ergibt sich aus der aus Deinen Äußerungen folgenden Ungleichung eine wenig schmeichelhafte Schlussfolgerung.
Viele Grüße, commodity
1
Hi,
10 Sekunden Google-Fu:
Quelle: https://community.cisco.com/t5/network-access-control/why-do-desktop-swi ...
When using PEAP EAP-MSCHAPv2 on an MS switchport, if an unmanaged switch is between the supplicant (user machine) and the RADIUS client (MS) the authentication will fail. The reasoning is explained below:
Jetzt würde ich aber immer noch gern verstehen, wie der unmanaged Switch auf seinem Layer das EAPoL rausfiltert.
10 Sekunden Google-Fu:
Quelle: https://community.cisco.com/t5/network-access-control/why-do-desktop-swi ...
When using PEAP EAP-MSCHAPv2 on an MS switchport, if an unmanaged switch is between the supplicant (user machine) and the RADIUS client (MS) the authentication will fail. The reasoning is explained below:
- The destination of the eapol (RADIUS exchange) frame is a special multicast address that 802.1D-compliant bridges do not forward.
- This destination is labeled as "nearest" in Wireshark which means that the frame should only be forwarded to the next layer 2 device.
- If the unmanaged switch is added into the topology between the client and the MS, the next layer 2 device is the unmanaged switch and because the multi-cast nearest address is not meant to traverse multiple switches, the unmanaged switch drops the packets. This prevents the client from being authorized.
2
Du bist super! Ja, sorry, ich denke gar nicht ans Googlen, wenn Kollege @aqui "in der Leitung" ist. Mein Fehler.
Die Erklärung ist nicht nur plausibel, sie belegt auch den ersten Post des Kollegen @madnem und erklärt die dortige Aussage technisch. Und auch die Ausführungen bei Wikipedia werden damit klarer, denn dort wird bei der Sicherheitslücke auch auf einen zwischen geklemmten Hub verwiesen.
Hier wird das im Rahmen der Beschreibung des Angriffs auf die ursprüngliche Implementierung nochmal sehr hübsch verdeutlicht, auch unter Benennung der "special address" (am Ende von Schritt 1):
https://blog.to.com/netzwerkzugangskontrolle-nach-802-1x-2004-umgehen/
(bisschen aufwendig vielleicht, wenn eigentlich ein Hub reicht, aber sehr gut aufbereitet).
Aber kein Standard ohne Ausnahme:
impliziert, dass auch Clients das überwinden können. Für die hiesige Frage aber irrelevant.
Sehr spannende Geschichte! Wieder was gelernt, danke, dass Du dran geblieben bist.
Viele Grüße, commodity
Die Erklärung ist nicht nur plausibel, sie belegt auch den ersten Post des Kollegen @madnem und erklärt die dortige Aussage technisch. Und auch die Ausführungen bei Wikipedia werden damit klarer, denn dort wird bei der Sicherheitslücke auch auf einen zwischen geklemmten Hub verwiesen.
Hier wird das im Rahmen der Beschreibung des Angriffs auf die ursprüngliche Implementierung nochmal sehr hübsch verdeutlicht, auch unter Benennung der "special address" (am Ende von Schritt 1):
https://blog.to.com/netzwerkzugangskontrolle-nach-802-1x-2004-umgehen/
(bisschen aufwendig vielleicht, wenn eigentlich ein Hub reicht, aber sehr gut aufbereitet).
Aber kein Standard ohne Ausnahme:
If any intermediate device between the client and the authentication server does not support the multicast address, you must use an 802.1X client that can send broadcast EAPOL-Start packets.
https://techhub.hpe.com/eginfolib/networking/docs/switches/5130ei/5200-3 ...impliziert, dass auch Clients das überwinden können. Für die hiesige Frage aber irrelevant.
Sehr spannende Geschichte! Wieder was gelernt, danke, dass Du dran geblieben bist.
Viele Grüße, commodity
