- 802.1X mit FreeRADIUS ermöglicht die Zuweisung dynamischer VLANs mithilfe von Standard-RADIUS-Attributen.
- Controller wie Omada und ExtremeCloud IQ integrieren FreeRADIUS gut, um kabelgebundene und WLAN-Nutzer zu trennen.
- Fehler bei LDAP-Abfragen, unsichere EAP-Methoden oder falsch konfigurierte Switches führen zu Problemen bei der VLAN-Zuweisung.
- Eine gute Planung und Erprobung der Richtlinien beugen Problemen mit RDP, älteren Geräten und hybriden Umgebungen vor.
Wenn Sie kabelgebundene oder WLAN-Netzwerke verwalten und den Datenverkehr nach Benutzertyp trennen möchten, ohne auf eine teure NAC-Lösung zurückgreifen zu müssen, ist die effektive Nutzung von 802.1X, FreeRADIUS und dynamischer VLAN-Zuweisung eine der leistungsstärksten Möglichkeiten. Es lohnt sich zu verstehen, wie dies mit der Zero-Trust-Architektur zusammenhängt . Bei korrekter Implementierung können Sie anhand des Benutzers, seines Standorts oder der zugehörigen Verzeichnisgruppe festlegen, mit welchem Netzwerk sich jedes Gerät verbindet – ohne überall SSIDs erstellen oder an einen einzelnen Hersteller gebunden zu sein.
In diesem Artikel erklären wir Ihnen detailliert, wie alles zusammenpasst: die Rolle von 802.1X, typische FreeRADIUS-Konfigurationen, RADIUS-Attribute für VLANs, die Integration mit WLAN-Controllern und Switches , Praxisbeispiele (Omada, ExtremeCloud IQ, klassische Switches), häufige Probleme und sogar fortgeschrittene Themen wie Azure AD und fehlerhafte Attribute in LDAP. Ziel ist es, Ihnen am Ende ein klares und praktisches Verständnis zu vermitteln und Sie in die Lage zu versetzen, das Gelernte auf Ihre eigene Infrastruktur anzuwenden – egal ob klein oder groß.
802.1X und dynamische VLANs: Grundlegende Konzepte und Komponenten
Der 802.1X-Standard fungiert vereinfacht gesagt als Zugangskontrolle Ihres Netzwerks: Solange sich ein Gerät nicht authentifiziert hat, gewährt ihm der Port oder das WLAN keinen Zugriff auf das Netzwerk. Um eine echte Segmentierung zu erreichen, wird er mit der dynamischen VLAN-Zuweisung mithilfe von RADIUS-Attributen kombiniert . Der Server entscheidet also, welchem VLAN jeder Client nach der Authentifizierung zugewiesen wird.
Bei jeder 802.1X-Implementierung gibt es drei Schlüsselkomponenten, die immer vorhanden sind, unabhängig davon, ob Sie Omada, ExtremeCloud IQ oder generische Switches verwenden:
- Bittsteller: der Client, der eine Verbindung herstellen möchte (Laptop, Mobiltelefon, „bereiter“ Drucker usw.).
- Authenticator: die Netzwerkgeräte, die den Zugriff steuern (Switch, Access Point oder Wi-Fi-Controller) und mit dem RADIUS-Server kommunizieren.
- Authentifizierungsserver: normalerweise ein RADIUShäufig FreeRADIUS, das die Anmeldeinformationen überprüft und die Richtlinien festlegt (erlauben, verweigern, in ein bestimmtes VLAN einordnen).
Die Magie dynamischer VLANs liegt in den RADIUS-Attributen des Access-Accept-Protokolls . Nahezu alle VLAN-Hersteller verstehen die Kombination tunnelartiger Attribute:
- Tunneltyp = VLAN
- Tunnel-Medium-Typ = IEEE-802
- Tunnel-Private-Group-Id = "VLAN-ID" (normalerweise eine Zahl zwischen 1 und 4095, wird aber als Text gesendet)
Wenn der Switch oder Access Point ein Access-Accept mit diesen Attributen empfängt, weist er, sofern er 802.1X und dynamische VLANs unterstützt, den Port oder die Wi-Fi-Sitzung dem vom RADIUS angegebenen VLAN zu und ignoriert dabei das Standard-VLAN oder die Standard-SSID des Ports (es sei denn, der RADIUS sendet nichts; in diesem Fall wendet er seine lokale Konfiguration an).
FreeRADIUS-Konfiguration für dynamische VLANs
FreeRADIUS ist der Inbegriff eines Open-Source-RADIUS-Servers. Er lässt sich auf jedem gängigen Linux-System installieren , sogar auf sehr kleiner Hardware wie dem NanoPi NEO oder Raspberry Pi, und bewältigt bei korrekter Konfiguration auch anspruchsvollste Umgebungen. Für dynamische VLANs sind zwei Aspekte entscheidend: die Definition von Benutzern/Gruppen und die korrekte Einbindung der Module in die Verarbeitungskette.
In einfachen Installationen können Testbenutzer direkt in der FreeRADIUS - Benutzerdatei definiert und ihnen das VLAN zugewiesen werden, das sie empfangen sollen. Die typische Datei befindet sich unter Debian/Ubuntu unter /etc/freeradius/3.0/users , und die VLAN-Einträge sehen folgendermaßen aus (vereinfacht und umgeschrieben):
Mitarbeiter10 Klartext-Passwort := "key10" Diensttyp := Framed-User, Tunneltyp := VLAN, Tunnelmediumtyp := IEEE-802, Tunnel-Private-Group-Id := "10" Mitarbeiter20 Klartext-Passwort := "key20" Diensttyp := Framed-User, Tunneltyp := VLAN, Tunnelmediumtyp := IEEE-802, Tunnel-Private-Group-Id := "20"
Mit dieser Struktur sendet FreeRADIUS nach einem Access-Accept die drei Tunnelattribute zurück, sodass das NAS (Switch oder Access Point) den Client je nach Benutzer in VLAN 10 oder 20 einordnen kann. Wichtig ist, dass die Netzwerkgeräte die entsprechende RFC unterstützen und diese Attribute vor dem konfigurierten Zugriffs-VLAN berücksichtigen.
In manchen Szenarien, wie beispielsweise der Integration mit ExtremeCloud IQ, ist es entscheidend, dass diese Attribute präzise in der Access-Accept-Anweisung gesendet werden und nicht nur als „getunnelte“ Attribute in anderen Phasen des EAP-Prozesses. In Standardkonfigurationen verarbeitet FreeRADIUS möglicherweise zuerst das EAP- Modul und anschließend das Dateien- Modul (das die Benutzerdatei liest). Dadurch gehen dem Controller die Attribute zum entscheidenden Zeitpunkt verloren.
Die bewährte Lösung besteht darin, die Datei `/etc/freeradius/3.0/ sites-enabled/default` anzupassen und das Modul `files` innerhalb des `authorize`- Blocks vor `eap` zu verschieben. Dadurch lädt FreeRADIUS zuerst die statischen Benutzerattribute (einschließlich VLAN) und verarbeitet anschließend das EAP, sodass beim Erstellen des finalen `Access-Accept` die Tunnelattribute an der vom Controller erwarteten Stelle enthalten sind.
Eine weitere empfohlene Anpassung ist die Deaktivierung schwacher EAP-Methoden wie EAP-MD5 , die nie für Produktionsumgebungen vorgesehen waren. Durch Bearbeiten der Datei `/etc/freeradius/3.0/ mods-enabled/eap` und Auskommentieren oder Löschen des MD5-Abschnitts deaktiviert FreeRADIUS diese Methode. Es empfiehlt sich, die Konfiguration auf robuste Methoden wie EAP-TLS (Zertifikate) oder PEAP mit MSCHAPv2 zu konzentrieren.
VLAN-Zuweisung mit Omada: Interner RADIUS und externer FreeRADIUS
Das Omada-Ökosystem von TP-Link (Controller + Switches + Access Points) integriert 802.1X mit dynamischen VLANs hervorragend, sowohl über den internen RADIUS-Server als auch durch Delegierung an einen externen FreeRADIUS-Server. Es ist ein sehr anschauliches Beispiel, da der gesamte Workflow klar nachvollziehbar ist.
Um den im Omada-Controller integrierten RADIUS-Server zu nutzen, ist üblicherweise ein dreistufiges Verfahren erforderlich. Zunächst wird im globalen Menü des Controllers der integrierte RADIUS-Server aktiviert, indem die IP-Adresse (die des Controllers selbst) angegeben und die Option „Tunneled Reply“ aktiviert wird , damit die Tunnelattribute korrekt an das Zugriffsgerät gesendet werden.
Sobald Sie sich auf der entsprechenden Website befinden, gehen Sie zu Einstellungen > Profil > RADIUS-Profil , bearbeiten Sie das Profil und erstellen Sie interne RADIUS-Benutzer. Omada ermöglicht es Ihnen, für jeden Benutzer einen Namen, ein Passwort und eine VLAN-ID festzulegen . So sendet der Controller nach der Authentifizierung des Benutzers die VLAN-Attribute direkt an den Switch oder Access Point, ohne Umweg über einen externen Server.
Aktivieren Sie abschließend unter Einstellungen > Authentifizierung > 802.1X die Option 802.1X, wählen Sie das interne RADIUS-Profil aus und aktivieren Sie explizit die VLAN-Zuweisung . Wählen Sie im selben Abschnitt die Switch-Ports aus, die eine 802.1X-Authentifizierung erfordern. Nach dem Speichern muss sich jedes Gerät, das sich mit diesen Ports verbindet, authentifizieren. Wenn dem Konto eine VLAN-ID zugewiesen ist, wird es automatisch diesem VLAN zugeordnet.
Wenn wir alles auf einem externen FreeRADIUS-Server zentralisieren möchten, unterstützt Omada dieses Szenario optimal. Im ersten Schritt bearbeiten wir die Datei clients.conf auf dem FreeRADIUS-Server, um den Controller (oder den Bereich, in dem sich die Switches/Access Points befinden) als RADIUS-Client zu autorisieren. Dazu geben wir die IP-Adresse bzw. das Subnetz und das gemeinsame Geheimnis an , das wir später in Omada konfigurieren.
Erstellen Sie anschließend in Omada unter Einstellungen > Profile > RADIUS-Profil ein externes RADIUS-Profil . Geben Sie dort die FreeRADIUS-IP-Adresse, den Authentifizierungsport (üblicherweise 1812) und das gemeinsame Passwort ein. Wählen Sie in den 802.1X-Einstellungen des Controllers dieses externe Profil aus und aktivieren Sie die VLAN-Zuweisung erneut . Markieren Sie dabei die Ports oder SSIDs, die Sie schützen möchten.
Eine weitere Überprüfung kann direkt am Controller erfolgen: Öffnen Sie unter „Tools > Terminal“ eine Konsole für den Switch mit aktiviertem 802.1X und führen Sie den Befehl „ show dot1x auth-state“ aus . Bei korrekter Funktion werden der authentifizierte Port und das von RADIUS zugewiesene VLAN angezeigt (z. B. Port 1/0/1 authentifiziert und VLAN 2 zugeordnet).
Dynamisches VLAN über WLAN mit FreeRADIUS und ExtremeCloud IQ
Ein weiteres sehr umfassendes Beispiel sind WLAN-Netzwerke, die von ExtremeCloud IQ (XIQ) mit FreeRADIUS als Authentifizierungsserver verwaltet werden. Hier wird das dynamische VLAN primär den WLAN-Clients anhand der von FreeRADIUS zurückgegebenen Tunnelattribute zugewiesen.
Zunächst einmal ist FreeRADIUS darauf vorbereitet, diese drei Attribute im Access-Accept zu senden, genau wie zuvor: Einträge in /etc/freeradius/3.0/users mit Benutzern und ihren VLANs sowie die Einstellung in sites-enabled/default , sodass das Modul files vor eap verarbeitet wird , da XIQ die Attribute genau im Accept erwartet.
Es wird dringend empfohlen, EAP-MD5 zu deaktivieren und stattdessen Methoden wie PEAP/EAP-TLS zu verwenden . Nach der Änderung der EAP-Konfigurationsdatei starten Sie den Dienst mit ` systemctl restart freeradius` neu, um die Änderungen zu übernehmen. Anschließend kann der Server Anfragen der von XIQ verwalteten Zugangspunkte beantworten.
Auf der Extreme-Cloud-Seite gibt es zwei relevante Kontotypen: das kostenlose Connect-Konto , das die grundlegende Verwaltung von bis zu zehn Geräten ermöglicht, aber keine erweiterten Klassifizierungsregeln für dynamische VLANs unterstützt, und die Pilot- Version , die eine 90-tägige Testphase bietet und den vollen Satz an Profilen und Regeln auf Basis von RADIUS-Attributen ermöglicht.
Erstellen Sie mit dem Pilot-Konto eine neue Netzwerkrichtlinie über das Menü „Konfigurieren > Netzwerkrichtlinien“, benennen Sie diese und wählen Sie zur Vereinfachung „Nur WLAN“ aus. Definieren Sie im zweiten Schritt die SSID, typischerweise ein Unternehmensnetzwerk mit WPA2 oder WPA3, und ordnen Sie eine RADIUS-Gruppe zu . Fügen Sie beim Erstellen dieser Gruppe FreeRADIUS als externen Server hinzu und geben Sie dessen IP-Adresse, Passwort und die Ports 1812/1813 an.
Anschließend werden Benutzerprofile konfiguriert . Dabei handelt es sich in der Praxis um Zugriffsprofile, die verschiedenen VLANs zugeordnet sind (z. B. VLAN10 und VLAN20). Es gibt ein Standardprofil, das Clients zugewiesen wird, deren RADIUS keine Tunnelattribute zurückgibt. Für dynamische VLANs werden die Zuweisungsregeln anhand des Werts der Tunnel-Private-Group-ID und anderer RADIUS-Attribute definiert.
Die Regeln besagen einfach: „Wenn die vom Accept-Request übermittelte Tunnel-Private-Group-ID 10 lautet, weise dem Benutzerprofil VLAN 10 zu“; lautet sie 20, weise dem Benutzerprofil VLAN 20 zu usw. ExtremeCloud IQ setzt diese Regeln in der Praxis um, indem der Client dem VLAN zugeordnet wird, dessen Attribut mit dem von FreeRADIUS gesendeten übereinstimmt.
Abschließend müssen Sie den Zugriff auf diese VLANs auf der kabelgebundenen Seite des Access Points (AP) erlauben, indem Sie das AP-Profil in XIQ so anpassen, dass der Uplink-Port alle konfigurierten VLANs zulässt und das native VLAN (üblicherweise VLAN 1) beibehält. Sobald alle Einstellungen gespeichert und die Netzwerkrichtlinie auf die APs angewendet wurde, können Sie mit dem in XIQ integrierten RADIUS-Testtool überprüfen, ob FreeRADIUS erreichbar ist und der Server für jeden Benutzer das erwartete VLAN-Attribut zurückgibt.
Omada SDN mit FreeRADIUS: VLANs für kabelgebundene und drahtlose Netzwerke
Die SDN-Lösung von Omada ermöglicht zudem die gleichzeitige Zuweisung dynamischer VLANs über kabelgebundene und drahtlose Netzwerke hinweg mithilfe eines externen RADIUS-Servers wie FreeRADIUS. Dadurch entfällt die Notwendigkeit, mehrere verschiedene SSIDs zu erstellen oder statische PVIDs an Switch-Ports zu verwenden.
Die typische Topologie umfasst einen Omada-Controller, EAP-Zugangspunkte, JetStream-Switches und einen FreeRADIUS-Server unter Linux. Damit Netzwerkgeräte Authentifizierungsanfragen an den Server senden können, wird die Datei clients.conf bearbeitet . Dabei wird der Client auf den Omada-Netzwerkbereich (z. B. 192.168.0.0/24) und ein gemeinsames Passwort festgelegt.
Anschließend werden die Benutzerkonten in der Benutzerdatei eingerichtet . Dabei werden beispielsweise zwei Benutzer definiert: einer für VLAN 10 und ein weiterer für VLAN 20, jeweils mit den Attributen Tunnel-Type, Tunnel-Medium-Type und Tunnel-Private-Group-Id. Bei WPA-Enterprise ist es üblich, auch die EAP-Konfigurationsdatei anzupassen , um die Methode an den Clienttyp anzupassen (z. B. EAP-PEAP für Windows-Laptops).
Erstellen Sie im Omada-Controller im Bereich „Authentifizierung“ ein RADIUS-Profil, das auf FreeRADIUS verweist, und aktivieren Sie die Option „VLAN-Zuweisung für drahtlose Netzwerke aktivieren“ . Dadurch wird sichergestellt, dass Omada bei der WPA-Enterprise-Authentifizierung eines Clients den RADIUS-Server abfragt und das Gerät dem vom Server zurückgegebenen VLAN zuordnet, anstatt dem statischen VLAN der SSID.
Außerdem müssen die VLAN-Schnittstellen des Netzwerks unter Einstellungen > Kabelgebundene Netzwerke > LAN definiert werden . Erstellen Sie beispielsweise zwei logische Schnittstellen für VLAN10 und VLAN20 mit ihren jeweiligen IP-Gateways. Dadurch erhält ein Client in VLAN10 eine IP-Adresse innerhalb des Adressbereichs dieses VLANs , und dasselbe gilt für VLAN20.
Im WLAN wird eine SSID mit WPA-Enterprise erstellt, die auf das RADIUS-Profil verweist. Verbindet sich ein Client beispielsweise mit dem Benutzernamen „test10“ und authentifiziert sich, erhält er eine IP-Adresse aus VLAN 10; verwendet er hingegen den Benutzernamen „test20“, wird er VLAN 20 zugewiesen. So ist es nicht nötig, für jeden Fall eine separate SSID zu erstellen.
Auf der kabelgebundenen Seite ist die Logik ähnlich, verwendet jedoch 802.1X Port-Based . 802.1X wird im entsprechenden Abschnitt des Controllers aktiviert, der Typ „Port-basiert“ ausgewählt, die „VLAN-Zuweisung“ aktiviert und die Ports, die eine Authentifizierung erfordern, markiert. Anschließend wird diesen Ports ein Portprofil zugewiesen , das VLAN10 und VLAN20 als ungetaggte Netzwerke hinzufügt. Dabei wird sichergestellt, dass der 802.1X-Steuerungsmodus auf „Auto“ eingestellt ist, sodass der Switch die Aushandlung initiiert, sobald er einen Client erkennt.
Mit einer einzigen RADIUS-Konfiguration und einigen wenigen Profilen stellt Omada SDN sicher, dass sowohl kabelgebundene als auch WLAN-Benutzer entsprechend ihren Zugangsdaten im jeweiligen VLAN landen , ohne dass Netzwerke vervielfacht oder die Konfiguration jedes Ports manuell angepasst werden muss.
Praktische Beispiele, häufige Fehler und Konfigurationstipps
Die Arbeit mit FreeRADIUS und dynamischen VLANs ist nicht immer einfach: Beim Übergang von Labortests in reale Umgebungen treten immer wieder Probleme auf, insbesondere im Umgang mit LDAP/AD-Verzeichnissen, Benutzernamenformaten und komplexen Richtlinien . Ein gutes Cybersicherheits-Risikomanagement trägt daher wesentlich zur Reduzierung von Sicherheitsvorfällen bei.
Ein sehr typischer Fehler tritt auf, wenn der Server eine LDAP-Abfrage unter Verwendung des Attributs erstellt. %{User-Name} so wie es in RADIUS ankommt. In vielen Windows-Szenarien kommt das Format an als DOMÄNE\Benutzer, wobei der Backslash als kodiert wird 5cWenn die LDAP-Vorlage mit uid=%{User-Name}Die resultierende Abfrage wird etwa so aussehen: uid=DOMINIO\5cusuarioDie Übereinstimmung mit der tatsächlichen Benutzer-ID im LDAP-Baum ist selten, daher werden null Ergebnisse zurückgegeben.
Das bedeutet, dass die Benutzerattribute, einschließlich des zuzuordnenden VLAN- oder Gruppenwerts , im Verzeichnis nicht gefunden werden. Daher fügt der Server die Tunnel-Private-Group-Id nicht hinzu, und der Client verbleibt im Standard-VLAN des Switches oder Access Points. Dieses Muster ist in den FreeRADIUS-Protokollen deutlich erkennbar: eine LDAP-Abfrage mit der UID „domain\5user“ und leerem Suchergebnis.
Die praktische Lösung, die sich bewährt hat, besteht darin, die Verwendung von %{User-Name} in der LDAP-Abfragevorlage in der FreeRADIUS-Konfiguration durch %{Stripped-User-Name} zu ersetzen, z. B.:
if ("%{ldap:ldap:///dc=example,dc=com?uid?sub?(|(uid=%{Stripped-User-Name})(macAddress=%{Calling-Station-Id}))}") { ... }
Auf diese Weise verwendet FreeRADIUS den „sauberen“ Benutzernamen ohne Domäne oder Schrägstrich, und die Suchvorgänge sind wieder erfolgreich. Sobald LDAP den korrekten Eintrag zurückgibt, kann der Server die Logik zur VLAN-Zuweisung basierend auf Gruppen, Organisationseinheiten oder spezifischen Attributen anwenden und Tunnel-Type, Tunnel-Medium-Type und Tunnel-Private-Group-Id im Access-Accept erneut generieren.
Ein weiterer interessanter Fall tritt bei einigen Switches auf, wenn statische VLAN-Konfigurationen an einem Port mit dynamischen 802.1X-Konfigurationen vermischt werden. Beispielsweise könnte Port 17 im statischen VLAN 4 konfiguriert sein, während gleichzeitig versucht wird, einen bestimmten Benutzer per RADIUS in VLAN 2 zu zwingen. Wenn das Gerät Tunnelattribute nicht berücksichtigt oder die dynamische VLAN-Funktion deaktiviert ist, wird der Datenverkehr an diesem Port weiterhin als VLAN 4 behandelt, unabhängig von den RADIUS-Einstellungen.
In solchen Situationen ist es unerlässlich, die Dokumentation des Switches zu konsultieren, um die VLAN-Zuweisung via RADIUS explizit zu aktivieren und mithilfe von Befehlen wie ` show dot1x` oder ähnlichen Befehlen zu debuggen. Dabei ist zu prüfen, ob das Gerät Meldungen wie „Tunnelattribute werden ignoriert“ oder „Dynamische VLAN-Zuweisung deaktiviert“ ausgibt. Nur wenn der Hersteller dies unterstützt und die Funktion aktiviert ist, landet ein Benutzer, der standardmäßig an einen physischen Port in VLAN 4 angeschlossen ist, nach der Authentifizierung als „carlos“ oder einem anderen Benutzer tatsächlich in VLAN 2.
Es gibt auch klassische Diskussionen über die Eignung dynamischer VLANs in Remote-Desktop-Szenarien (RDP) . Wenn die Computerauthentifizierung beim Windows-Start und die Benutzerauthentifizierung beim Anmelden erfolgt, kann der durch die Benutzeranmeldung ausgelöste VLAN-Wechsel laufende RDP-Sitzungen unterbrechen oder DNS-Probleme verursachen, da der Port vom Computer-VLAN zum Benutzer-VLAN wechselt. Viele Administratoren haben sich in diesen Fällen dafür entschieden, ein einziges VLAN für alle Zustände zu verwenden oder dasselbe VLAN sowohl auf Computer- als auch auf Benutzerebene zuzuweisen, um Segmentwechsel zu minimieren.
Schließlich wächst auf der Ebene der fortgeschrittenen Integration das Interesse an der Verknüpfung von FreeRADIUS mit Azure AD , um VLANs anhand der Gruppenzugehörigkeit in der Cloud zu bestimmen. Aktuell existiert kein offizielles natives Modul für die direkte Gruppenabfrage von VLANs in Azure AD. Workarounds erfordern externe Skripte, Aufrufe der Microsoft Graph API und einige Anpassungen. Da es sich um ein dynamisches Feld handelt, wird diese Logik häufig an ein kommerzielles NAC-System oder eine andere Zwischenkomponente delegiert, wenn eine stabile und unterstützte Lösung benötigt wird.
Durch die effektive Kombination von 802.1X, FreeRADIUS und dynamischer VLAN-Zuweisung lässt sich eine präzise Netzwerksegmentierung ohne aufwendige NAC-Lösungen realisieren. Dies passt ideal zu einer robusten IT-Sicherheitsstrategie für Unternehmen : Von Controllern wie Omada oder ExtremeCloud IQ bis hin zu Midrange-Switches – alle Komponenten tragen dazu bei, sofern Tunnelattribute beachtet, LDAP/AD-Abfragen sorgfältig verwaltet und die dynamische Verschiebung von Benutzern in andere VLANs anhand ihrer Identität, Rolle oder des angeschlossenen Gerätetyps klar definiert ist.
