17
Mikrotik: Dynamische VLAN-Zuweisung für WLAN mit Passwort-Authentifizierung
Hallo,
ich betreibe ein Netzwerk mit WLAN mit 4 VLANs. Aktuell wird für jedes VLAN ein WLAN mit eigener MSSID aufgebaut. Zur Vermeidung der mehrfachen WLANs wollte ich auf eine dynamische Zuweisung der VLAN-ID anhand der MAC des jeweiligen Rechners umsteigen. Die Authentifizierung sollte über ein einfaches Passwort (gern auch ein spezifisches für jeden Nutzer) erfolgen. Da auch IoT-Geräte betrieben werden sollen, scheidet eine Authentifizierung mit eine User/Passwort-Kombination oder Zertifikat aus.
Die Basiskonfiguration habe ich entsprechend Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik auf einem hACac² mit der SW 7.6 aufgesetzt. Grundsätzlich funktioniert die Anmeldung am Router sowohl über einen externen FreeRadius als auch über den User Manager des Routers. Die folgenden Attribute habe ich in beiden Radius-Servern gesetzt:
Allerdings wird das jeweilige cap-Interface in der Bridge nur am Trunc-VLAN als Untagged eingetragen, nicht aber beim vergebenen VLAN als tagged. Damit erreichen die IP-Pakete des Clients nicht das Netz bzw. die Gegenrichtung nicht den Client. Schon das DHCP kommt nicht durch und die Anmeldung kann nicht abgeschlossen werden. Was geht hier schief bzw. was könnte an meiner Konfiguration fehlen?
Frank
PS: Das Ergebnis unterscheidet sich damit nicht von der Zuweisung des VLANs über die MAC-Access Lists im CAPsMAN (siehe Mikrotik Capsman: VLAN-ID Access List).
ich betreibe ein Netzwerk mit WLAN mit 4 VLANs. Aktuell wird für jedes VLAN ein WLAN mit eigener MSSID aufgebaut. Zur Vermeidung der mehrfachen WLANs wollte ich auf eine dynamische Zuweisung der VLAN-ID anhand der MAC des jeweiligen Rechners umsteigen. Die Authentifizierung sollte über ein einfaches Passwort (gern auch ein spezifisches für jeden Nutzer) erfolgen. Da auch IoT-Geräte betrieben werden sollen, scheidet eine Authentifizierung mit eine User/Passwort-Kombination oder Zertifikat aus.
Die Basiskonfiguration habe ich entsprechend Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik auf einem hACac² mit der SW 7.6 aufgesetzt. Grundsätzlich funktioniert die Anmeldung am Router sowohl über einen externen FreeRadius als auch über den User Manager des Routers. Die folgenden Attribute habe ich in beiden Radius-Servern gesetzt:
- Tunnel-Type: 13
- Tunnel-Medium-Type: 6
- Tunnel-Private-Group-ID: 5
- Mikrotik-Wireless-VLANID: <VLAN-ID>
- Mikrotik-Wireless-VLANIDtype: 0
- Mikrotik-Wireless-Comment: <PC-Name>
Allerdings wird das jeweilige cap-Interface in der Bridge nur am Trunc-VLAN als Untagged eingetragen, nicht aber beim vergebenen VLAN als tagged. Damit erreichen die IP-Pakete des Clients nicht das Netz bzw. die Gegenrichtung nicht den Client. Schon das DHCP kommt nicht durch und die Anmeldung kann nicht abgeschlossen werden. Was geht hier schief bzw. was könnte an meiner Konfiguration fehlen?
Frank
PS: Das Ergebnis unterscheidet sich damit nicht von der Zuweisung des VLANs über die MAC-Access Lists im CAPsMAN (siehe Mikrotik Capsman: VLAN-ID Access List).
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5257372514
Url: https://administrator.de/forum/mikrotik-dynamische-vlan-zuweisung-fuer-wlan-mit-passwort-authentifizierung-5257372514.html
Ausgedruckt am: 27.12.2024 um 00:12 Uhr
17 Kommentare
Neuester Kommentar
Hallo Mirko,
der Titel ist nicht ganz zufällig ähnlich und wie im geschrieben, habe ich die Konfiguration als Grundlage genommen. Die Authenifikation per Radius funktioniert, nur der anschließende Traffic nicht, da das dynamisch angelegte Interface nicht als Tagged in die Bridge eingetragen wird (taucht nur als untagged für VLAN1 auf). Habe die Konfiguration mehrfach geprüft, aber keine Stelle gefunden, die das bewirken sollte...
Frank
der Titel ist nicht ganz zufällig ähnlich und wie im geschrieben, habe ich die Konfiguration als Grundlage genommen. Die Authenifikation per Radius funktioniert, nur der anschließende Traffic nicht, da das dynamisch angelegte Interface nicht als Tagged in die Bridge eingetragen wird (taucht nur als untagged für VLAN1 auf). Habe die Konfiguration mehrfach geprüft, aber keine Stelle gefunden, die das bewirken sollte...
Frank
Die Anschlussports der APs (cAP etc.) musst du natürlich statisch mit den VLANs tagged versehen die du dynamisch in den APs zuweist. Andernfalls landen die durch die APs getaggten Frames natürlich im Nirvana. Steht aber auch alles mehrfach im o.a. Tutorial und zusätzlich u.a. auch HIER!
Lesen und verstehen! 😉
Lesen und verstehen! 😉
Wer ist denn Mirko?
1
@Kuemmel: Es gab um halb 8 einen Kommentar von MirkoKR, dass es der zu grundeliegende Artikel von aqui wieder unter die Top6 geschafft hat. Aus unerfindlichen Gründen ist dieser Beitrag wieder verschwunden...
@aqui: Vielen Dank für Deine Rückmeldung, habe ich jetzt auch gefunden. Allerdings passt an dieser Stelle die Beschreibung nicht ganz zu meinem Aufbau...
Aktuell habe ich die gesamte Konfiguration auf einem hAPac². Die beiden CAPs für 2,4 GHz und 5 GHz sind damit nicht über Ethernet angeschlossen, sondern werden dynamisch zur Laufzeit, teilweise unter wechselnden Namen angelegt. HW-Ports kann man natürlich als Trunk fest als untagged in der Bridge-VLAN-Konfiguration eintragen. Aber wie mache ich das mit den dynamisch angelegten cap-Schnittstellen. Die werden nur untagged für Trunk-Ports dynamisch eingetragen, nicht aber als tagged bei den Nutzer-VLANs. Wenn ich sie per Hand als untagged konfiguriere, funktioniert das WLAN. Allerdings sind die nach einem Reboot wieder weg.
Unabhängig davon sind mir im Beitrag zwei Kleinigkeiten aufgefallen:
HW-Architektur:
Entsprechend Bild1 werden 3 CAPs betrieben, ein an Ether9 und zwei weitere über einen Switch an Ether5. Entsprechend der Beschreibung der Bridge-VLAN würde ich allerdings erwarten, dass:
CAPsMAN-Konfiguration:
Aus anderen Beschreibungen kenne ich noch einen Eintrag bei Provisioning, der die erstellte Konfiguration zur Nutzung durch CAPsMAN frei gibt. Diese Definition habe ich in der Beschreibung aber nicht gefunden. Geht es auch ohne? Was sind dann die Unterschiede.
VLAN-Steuerung über die Access-List:
Das hatte neipsi hier schon mal mit Dir diskutiert. Das Verhalten ist das Gleiche: Die caps werden bei Anmeldung eines Clients im Trunc-Port als untagged eingetragen, allerdings nicht als tagged beim jeweiligen VLAN. Macht man es per Hand funktioniert es.
Ich habe den Eindruck, dass Access List und Radius-Server praktisch äquivalent sind, nur dass man bei der Access List jedem Nutzer ein eigenes Passwort geben kann. Siehst Du Nachteile?
@aqui: Vielen Dank für Deine Rückmeldung, habe ich jetzt auch gefunden. Allerdings passt an dieser Stelle die Beschreibung nicht ganz zu meinem Aufbau...
Aktuell habe ich die gesamte Konfiguration auf einem hAPac². Die beiden CAPs für 2,4 GHz und 5 GHz sind damit nicht über Ethernet angeschlossen, sondern werden dynamisch zur Laufzeit, teilweise unter wechselnden Namen angelegt. HW-Ports kann man natürlich als Trunk fest als untagged in der Bridge-VLAN-Konfiguration eintragen. Aber wie mache ich das mit den dynamisch angelegten cap-Schnittstellen. Die werden nur untagged für Trunk-Ports dynamisch eingetragen, nicht aber als tagged bei den Nutzer-VLANs. Wenn ich sie per Hand als untagged konfiguriere, funktioniert das WLAN. Allerdings sind die nach einem Reboot wieder weg.
Unabhängig davon sind mir im Beitrag zwei Kleinigkeiten aufgefallen:
HW-Architektur:
Entsprechend Bild1 werden 3 CAPs betrieben, ein an Ether9 und zwei weitere über einen Switch an Ether5. Entsprechend der Beschreibung der Bridge-VLAN würde ich allerdings erwarten, dass:
- ether 5 ein Access-Port ins Management-Netz ist
- ether10 der Trunc-Port
- nur zwei APs über ether8 und ether9 mit dem Router verbunden sind
CAPsMAN-Konfiguration:
Aus anderen Beschreibungen kenne ich noch einen Eintrag bei Provisioning, der die erstellte Konfiguration zur Nutzung durch CAPsMAN frei gibt. Diese Definition habe ich in der Beschreibung aber nicht gefunden. Geht es auch ohne? Was sind dann die Unterschiede.
VLAN-Steuerung über die Access-List:
Das hatte neipsi hier schon mal mit Dir diskutiert. Das Verhalten ist das Gleiche: Die caps werden bei Anmeldung eines Clients im Trunc-Port als untagged eingetragen, allerdings nicht als tagged beim jeweiligen VLAN. Macht man es per Hand funktioniert es.
Ich habe den Eindruck, dass Access List und Radius-Server praktisch äquivalent sind, nur dass man bei der Access List jedem Nutzer ein eigenes Passwort geben kann. Siehst Du Nachteile?
Aber wie mache ich das mit den dynamisch angelegten cap-Schnittstellen.
Dort muss man gar nichts machen, denn diese senden die authorisierten Frames ja schon direkt mit den Tags aus die der Radius zuweist. Du musst lediglich dafür sorgen das das Ziel diese Tags dann auch auswertet und die Frames ins richtige VLAN forwardet.Interne WLAN Ports sind dann immer Member der VLAN Bridge im Port Mode "Admit all".
Deine Beschreibung von "dynamischen" CAPs klingt zugegebenerweise etwas wirr, denn sowas existiert im CapsMan Umfeld gar nicht und verschwinden auch niemals nach einem Reboot was ja auch fatal wäre. Fragt sich also was du damit meinst?!? 🤔
ein an Ether9 und zwei weitere über einen Switch an Ether5.
Das ist nur stilisiert dargestellt und soll verdeutlichen das die APs nicht unbedingt direkt am MT angeschlossen sein müssen für ein zentrales CapsMan WLAN Management, sondern überall in der Infrastruktur liegen können.Tatsächlich befinden sich die beiden Test APs aus dem Tutorial Setup ohne den VLAN Switch direkt an den Ports eth9 und eth10 an einem RB2011. (Die WinBox Screenshots zeigen das)
ether 5 ein Access-Port ins Management-Netz ist
Nein. Wie du oben schon selber sagst ist das ein tagged Uplink Port auf einen VLAN L2 Switch.Direkte Access Ports im Management Netz (VLAN1) sind die Ports 1, 2 und 6, 7 bzw. alle Ports die untagged im VLAN 1 liegen inkl. VLAN Switch.
ether10 der Trunc-Port
Das ist richtig.Es ist einer der Anschlussports der beiden CAP APs. Trunk deshalb als das dort nur das Management VLAN 1 als PVID VLAN (untagged) anliegt und alle die im WLAN dynamisch den Usern zugewiesenen VLANs (tagged). Deshalb steht dieser Member Port in der VLAN Bridge im Mode "Admit all".
Dieser User spezifische Traffic kommt dort ja je nach Authentisierung entsprechend VLAN tagged an, da das gesamte Szenario ein local Termination Design nutzt ohne zentrales Tunneling auf den Controller. (Letzteres ist nicht skalierbar)
nur zwei APs über ether8 und ether9 mit dem Router verbunden sind
Auch das ist leider falsch. Tutorial lesen hilft wirklich! 
Wie die WinBox Screenshots dort ja eindeutig zeigen sind das eth9 und eth10. (2 APs mit den Namen "links" und "rechts" wie oben schon gesagt wurde)
der die erstellte Konfiguration zur Nutzung durch CAPsMAN frei gibt.
Was ja der tiefere Sinn des zentralen WLAN Managements mit der CapsMan Funktion ist und nichts anderes macht das Tutorial Setup ja auch. Was sollte CapsMan auch sonst machen?!Geht es auch ohne? Was sind dann die Unterschiede.
Ja, natürlich geht es auch ganz ohne zentrales CapsMan Management mit gleicher Funktion.Der einzige Unterschied ist, das die angeschlossenen APs dann alle einzeln, statisch per Hand konfiguriert werden müssen. (Standalone APs) Logisch, denn das zentrale Management entfällt ja dann ohne das CapsMan Manmagement.
Hättest du das Tutorial wirklich vollständig gelesen wäre dir der Link in den weiterführenden Links zu genau so einem Setup sicher nicht entgangen so so ein CapsMan freies Setup beschreibt.
WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN
Die caps werden bei Anmeldung eines Clients im Trunc-Port als untagged eingetragen
Das ist Unsinn, denn die CAP Interfaces sind nicht User anhängig sondern werden fest eingetragen wenn ein AP als Hardware vom CapsMan erkannt wurde und registriert ist.Angeschlossene APs müssen dafür im CapsMode gebootet werden. Das Tutorial weist explizit darauf hin.
Die CAPs bleiben dann so immer permanent in der MT Konfig und sind niemals "dynamisch". Sie sind einzig nur Hardware abhängig bzw. repräsentieren die Hardware APs. Mit Usern hat das rein gar nix zu tun!
Auch haben Access Listen in keiner Funktion etwas mit Radius Servern zu tun. 2 völlig verschiedene und voneinander unabhängige Funktionen.
Kann es sein das du hier ganz grundsätzlich etwas verwechselst?? Oder man missversteht deine Intention was du eigentlich machen willst.
Eine dynamische VLAN Zuweisung der WLAN User mit 802.1x oder MBP ist nur mit Accesslisten nicht möglich.
Dank aqui’s konstruktiver Hinweise habe ich mich mit der Konfiguration des hAPac² sowie den Fragen näher beschäftigt, die das Tutorial leider nicht abdeckt. Provisioning, dynamisch angelegte CAPs und Router, die zwei Geräte vereinigen: den eigentlichen Router und einen Access Point mit zwei Transmittern (2,5 und 5 GHz). Die dazugehörigen Interface sind wlan1 und wlan2, die von CAPsMAN z.B. als cap1 und cap2 eingebunden werden.
Neben der halbautomatischen Konfiguration, wie im Tutorial beschrieben, kann man über das Provisioning die Konfiguration auch vollständig CAPsMAN überlassen. Adressiert über die MAC-Adresse lassen sich erstellte Konfigurationen den CAPs zuweisen. Mit der default-MAC 00:00:00:00:00:00 werden alle CAPs adressiert. Offen gebliebene Einstellungen (z.B. die Kanäle) übernimmt CAPsMAN. Das führt in kleineren Netzen durchaus zu brauchbaren Ergebnissen.
Damit auch die Weiterleitung der Daten in die VLANs funktioniert, müssen die Interface korrekt tagged/untagged in der VLAN-Konfiguration der Bridge eingetragen sein. Je nachdem, ob in der Datapath-Konfiguration „Local Forwarding“ eingeschaltet ist oder nicht, erfolgt die Datenübergabe über wlan1/2 („yes“) bzw. cap1/2 („no“). Diese Interface müssen in den VLANs der Bridge jeweils als tagged eingetragen werden ("untagged" im default-VLAN setzt CAPsMAN). Für wlan1/2 als HW-Interface ist es kein Problem, da ihre Namen statisch sind...
Bei cap1/2 funktioniert das nicht, da sie dynamisch angelegt werden und sich die Nummern sich beim Reboot und auch zur Laufzeit ändern können. Ist man, aus welchen Gründen auch immer, auf "Local Forwarding" = "no" angewiesen, hilft nur die halbautomatische Konfiguration der CAPs über den CAPsMAN entsprechend aqui’s Tutorial. Die CAPs werden dadurch statisch und ändern ihre Namen nicht mehr.
Interessant hierbei ist, dass die Anbindung an die Bridge nur bei dynamisch vergebener VLAN-ID nicht funktioniert. Bei statischen VLANs per MSSID gibt es diese Probleme nicht: Dort werden die cap-Interface zur Laufzeit bei Bedarf bei den VLANs als tagged eingetragen und es funktioniert einfach (getestet mit Version 6.48.1). Außerdem wird bei dynamischer VLAN-ID-Vergabe beim Anmelden eines Nutzers im WLAN das entsprechende cap-Interface untagged im default-VLAN gesetzt (was bei den funktionierenden Konfigurationen nicht notwendig ist). Keine Ahnung, was der Hintergrund dafür ist. Könnte natürlich ein Bug sein und eigentlich sollte das VLAN als tagged gesetzt werden…
Während der Tests hatte ich den Effekt, dass obwohl die caps nicht als tagged im VLAN der Bridge konfiguriert waren, die Verbindung funktionierte. Ein Backup der Konfiguration zeigte dann das Gegenteil: cap1 und cap2 waren im VLAN tagged. Hier hatte die WinBox leider gelogen. Das ist ganz sicher ein Bug.
Für den Dialog zur Bridge/Ports ist das sicher korrekt. Die VLAN-Konfiguration der Bridge passt allerdings nicht dazu...
Neben der halbautomatischen Konfiguration, wie im Tutorial beschrieben, kann man über das Provisioning die Konfiguration auch vollständig CAPsMAN überlassen. Adressiert über die MAC-Adresse lassen sich erstellte Konfigurationen den CAPs zuweisen. Mit der default-MAC 00:00:00:00:00:00 werden alle CAPs adressiert. Offen gebliebene Einstellungen (z.B. die Kanäle) übernimmt CAPsMAN. Das führt in kleineren Netzen durchaus zu brauchbaren Ergebnissen.
Damit auch die Weiterleitung der Daten in die VLANs funktioniert, müssen die Interface korrekt tagged/untagged in der VLAN-Konfiguration der Bridge eingetragen sein. Je nachdem, ob in der Datapath-Konfiguration „Local Forwarding“ eingeschaltet ist oder nicht, erfolgt die Datenübergabe über wlan1/2 („yes“) bzw. cap1/2 („no“). Diese Interface müssen in den VLANs der Bridge jeweils als tagged eingetragen werden ("untagged" im default-VLAN setzt CAPsMAN). Für wlan1/2 als HW-Interface ist es kein Problem, da ihre Namen statisch sind...
Bei cap1/2 funktioniert das nicht, da sie dynamisch angelegt werden und sich die Nummern sich beim Reboot und auch zur Laufzeit ändern können. Ist man, aus welchen Gründen auch immer, auf "Local Forwarding" = "no" angewiesen, hilft nur die halbautomatische Konfiguration der CAPs über den CAPsMAN entsprechend aqui’s Tutorial. Die CAPs werden dadurch statisch und ändern ihre Namen nicht mehr.
Interessant hierbei ist, dass die Anbindung an die Bridge nur bei dynamisch vergebener VLAN-ID nicht funktioniert. Bei statischen VLANs per MSSID gibt es diese Probleme nicht: Dort werden die cap-Interface zur Laufzeit bei Bedarf bei den VLANs als tagged eingetragen und es funktioniert einfach (getestet mit Version 6.48.1). Außerdem wird bei dynamischer VLAN-ID-Vergabe beim Anmelden eines Nutzers im WLAN das entsprechende cap-Interface untagged im default-VLAN gesetzt (was bei den funktionierenden Konfigurationen nicht notwendig ist). Keine Ahnung, was der Hintergrund dafür ist. Könnte natürlich ein Bug sein und eigentlich sollte das VLAN als tagged gesetzt werden…
Während der Tests hatte ich den Effekt, dass obwohl die caps nicht als tagged im VLAN der Bridge konfiguriert waren, die Verbindung funktionierte. Ein Backup der Konfiguration zeigte dann das Gegenteil: cap1 und cap2 waren im VLAN tagged. Hier hatte die WinBox leider gelogen. Das ist ganz sicher ein Bug.
Ja, natürlich geht es auch ganz ohne zentrales CapsMan Management
Das war nicht die Frage. Es ging darum, ob man Provisioning verwenden kann oder die individuelle Konfiguration der CAPs immer per Hand gemacht werden muss. Wie dargestellt geht es auch vollautomatisch, wenn man sich mit den Mechanismen des CAPsMAN zur Vergabe der offenen Parameter zufrieden gibt...Das ist Unsinn, denn die CAP Interfaces sind nicht User anhängig sondern werden fest eingetragen wenn ein AP als Hardware vom CapsMan erkannt wurde und registriert ist.
Na ja, bei dynamischer Vergabe gibt es das cap2 nur so lange im VLAN1, wie der Nutzer versucht eine IP-Adresse zu bekommen, danach ist das Interface in der Spalte „untagged“wieder weg...Angeschlossene APs müssen dafür im CapsMode gebootet werden.
Das ist bei einem Gerät, dass sowohl den AP als auch den Router enthält nicht ganz so sinnvoll. Allerdings gibt es natürlich auch die Möglichkeit, diesen Teil der Konfiguration manuell einzustellen. Neben der eigentlichen Freigabe muss für den lokalen Zugriff die Firewall angepasst werden:/ip/firewall/filter
add action=accept chain=input src-address-type=local dst-address-type=local
add action=accept chain=input src-address=127.0.0.1 dst-address=127.0.0.1 protocol=udp dst-port=1812,1813,3799 comment="Allow RADIUS access"/interface wireless cap
set enabled=yes interfaces=wlan1,wlan2 discovery-interfaces=bridge bridge=bridge caps-man-addresses=127.0.0.1Auch haben Access Listen in keiner Funktion etwas mit Radius Servern zu tun. 2 völlig verschiedene und voneinander unabhängige Funktionen.
Auch hier war die eigentliche Frage, ob die beiden Funktionen nicht zum gleichen Ergebnis führen und damit äquivalent sind. Ziel im zitierten Thread war eine einfache Authentication über MAC und Passwort, nicht 802.1x. In beiden Fällen geht der Einstieg über die Access List. Bei der RADIUS-Variante erfolgt die Prüfung extern im RADIUS-Server (UserManager), bei der Access List über die Access List direkt. In beiden Fällen wird bzw. kann der Nutzer per MAC und Passwort authentifiziert werden und über Attribute bzw. über die Parameter der Liste einem VLAN zugeordnet werden. Ich habe es ausprobiert und keinen funktionalen Unterschied gefunden.ether 5 ein Access-Port ins Management-Netz ist
Nein. Wie du oben schon selber sagst ist das ein tagged Uplink Port auf einen VLAN L2 Switch.nur zwei APs über ether8 und ether9 mit dem Router verbunden sind
Auch das ist leider falsch. Tutorial lesen hilft wirklich! face-winkFür den Dialog zur Bridge/Ports ist das sicher korrekt. Die VLAN-Konfiguration der Bridge passt allerdings nicht dazu...
Die VLAN-Konfiguration der Bridge passt allerdings nicht dazu...
Du hast natürlich Recht, das ist ein Fauxpas im Tutorial!Die AP Ports müssen natürlich 9 und 10 sein wie es oben in der Bridge auch zuvor definiert wurde.
Local Forwarding sollte man wegen der deutlich besseren Performance und Skalierbarkeit immer vorziehen.
Gleiches Thema aber anderer Punkt:
Zum MT internen Radius kam im Tutorial noch eine interessante Frage auf.
Hast du im Rahmen deiner Tests ggf. einmal überprüft ob es so ein Fallback VLAN gibt im internen Radius Server wie es der FreeRadius liefert?
Der Hinweis im Mikrotik Forum mit der reject-vlan-id müsste eigentlich auch bei MacAuth/MBP passen zumal es da ja mit MBP auch konfiguriert ist?!
Wenn Du das Tutorial anpasst und ich mir was wünschen dürft, könntest Du eventuell:
- auch das Architekturbild entsprechend der Konfiguration anpassen
- "Damit haben die APs eine saubere Grundkonfig, melden sich am Manager an und können nun dem zuvor erstellen Konfig Profil zugewiesen werden." mit einem entsprechenden Bild ergänzen
- ein Hinweis spendieren, dass bei kombinierten Router/APs (z.B. hACac²) die wlanX-Interface als tagged in den VLANs der Bridge einzutragen sind
- bei der CAP-Konfiguration die händische Variante für die Kombi-HW erwähnen (insbesondere der lokale Zugriff scheint häufiger ein Problem zu sein)
Wäre das i-Tüpfelchen für ein super Tutorial...
- auch das Architekturbild entsprechend der Konfiguration anpassen
- "Damit haben die APs eine saubere Grundkonfig, melden sich am Manager an und können nun dem zuvor erstellen Konfig Profil zugewiesen werden." mit einem entsprechenden Bild ergänzen
- ein Hinweis spendieren, dass bei kombinierten Router/APs (z.B. hACac²) die wlanX-Interface als tagged in den VLANs der Bridge einzutragen sind
- bei der CAP-Konfiguration die händische Variante für die Kombi-HW erwähnen (insbesondere der lokale Zugriff scheint häufiger ein Problem zu sein)
Wäre das i-Tüpfelchen für ein super Tutorial...
Local Forwarding sollte man wegen der deutlich besseren Performance und Skalierbarkeit immer vorziehen.
Mein zuvor genutztes Tutorial hat zu diesem Punkt leider nichts erwähnt und so fehlte in meiner alten Konfiguration das Häkchen und es spielte auch bei 3 Stationen noch keine große Rolle. Wird in der neuen Konfiguration aber umgestellt, schon um den Ärger mit dynamischen Namen der CAPs zu vermeiden.Hast du im Rahmen deiner Tests ggf. einmal überprüft ob es so ein Fallback VLAN gibt im internen Radius Server...
Ich habe erst mal den UserManger nach einer entsprechenden Variante abgesucht, aber nichts gefunden. Eventuell könnte man aber zwei Einträge in der Access List des CAPsMAN eintragen: Die erste für den RADIUS, die zweite als Rückfall auf das Isolationsnetz mit Angabe der entsprechenden VLAN-ID. Funktioniert natürlich nur, wenn bei negativer Antwort des RADIUS der folgende Eintrag noch abgearbeitet wird. Müsste ich mal in den kommenden Tagen probieren...
Die Punkte oben passe ich sukzessive an! Danke für das Feedback!
Hallo aqui,
in Bezug auf die Isolationszelle habe ich mir die folgenden Varianten angesehen:
Default-Nutzer im User-Manager (so wie in FreeRadius)
So richtig erfolgreich war ich dabei nicht. Auf einen Eintrag wie "DEFAULT" reagiert das gute Stück nicht. Das Internet war auch unergiebig. Ausschließen, dass es einen Nutzer mit Sonderbehandlung gibt, kann ich natürlich nicht...
User-Manager + Access List
Die Access-Liste gab sich leider mit der Ablehnung durch den UserManager zufrieden.
Nur mit Access Liste
Die erste Erkenntnis war, dass die Access List als default-Antwort ein "accept" liefert (hatte ich zuvor noch nicht getestet). Damit ist der folgende Eintrag als letzter Eintrag in der Liste verpflichtend:
Zulässige MACs platziert man darüber, unbekannte Nutzer werden über diese Regel abgewiesen.
Natürlich nur, wenn man action auf "reject" setzt. Man könnte natürlich in dieser Regel auch "accept" eintragen, den vlan-mode auf "use tag" und die vlan-id auf die Isolationszelle / Gästenetz...
So klappt es auch mit den Gästen...
in Bezug auf die Isolationszelle habe ich mir die folgenden Varianten angesehen:
Default-Nutzer im User-Manager (so wie in FreeRadius)
So richtig erfolgreich war ich dabei nicht. Auf einen Eintrag wie "DEFAULT" reagiert das gute Stück nicht. Das Internet war auch unergiebig. Ausschließen, dass es einen Nutzer mit Sonderbehandlung gibt, kann ich natürlich nicht...
User-Manager + Access List
Die Access-Liste gab sich leider mit der Ablehnung durch den UserManager zufrieden.
Nur mit Access Liste
Die erste Erkenntnis war, dass die Access List als default-Antwort ein "accept" liefert (hatte ich zuvor noch nicht getestet). Damit ist der folgende Eintrag als letzter Eintrag in der Liste verpflichtend:
/caps-man access-list add disabled=no action=reject comment="reject all unknown MACs" Natürlich nur, wenn man action auf "reject" setzt. Man könnte natürlich in dieser Regel auch "accept" eintragen, den vlan-mode auf "use tag" und die vlan-id auf die Isolationszelle / Gästenetz...
So klappt es auch mit den Gästen...
OK, das wäre ja dann schon mal ein gangbarer Workaround. 😉
Unklar ist noch die Funktion "reject-vlan-id". Laut einem Thread im MT Forum sollte das auch klappen. Das muss ein Router OS Kommando sein denn ein MT Radius Attribut mit dem Namen gibt es nicht laut aktuellem Dictionary File.
Unklar ist noch die Funktion "reject-vlan-id". Laut einem Thread im MT Forum sollte das auch klappen. Das muss ein Router OS Kommando sein denn ein MT Radius Attribut mit dem Namen gibt es nicht laut aktuellem Dictionary File.
/interface dot1x server
add accounting=no auth-types=mac-auth interface=ether1 mac-auth-mode=\
mac-as-username-and-password radius-mac-format=XXXXXXXXXXXX \
reject-vlan-id=621
Dot1X ist für mich leider Neuland. Wenn ich den Ansatz richtig verstehe, bindet sich der Dot1X-Server auf das angegebene Interface, greift die Authentifizierungsinformationen ab und übergibt sie dem RADIUS-Client. Der lässt den User-Manager prüfen, ob der User berechtigt ist.
Mit einem Ethernet-Port funktionierte das auch ohne Problem. Für die Zuweisung von VLAN-IDs stehen 3 Einträge in der Dot1X-Konfiguration zur Verfügung:
Pferdefuß: Die WLAN-Interface fehlen bei der Auswahl der zu überwachenden Interface. Ich gehe mal davon aus, dass die über "Wireless" beim RADIUS angebunden werden sollen.
Mit einem Ethernet-Port funktionierte das auch ohne Problem. Für die Zuweisung von VLAN-IDs stehen 3 Einträge in der Dot1X-Konfiguration zur Verfügung:
- Reject VLAN ID: Hier kann man eine ID eintragen, allerdings konnte sich der User nicht anmelden.
- Guest VLAN ID: Geht anscheinend nur mit Dot1X-Authentifizierung, bei "mac auth" gibt es eine Fehlermeldung bei Bestätigung der Konfiguration.
- Server Fail VLAN ID: Hier wird der nicht-autorisierte User in das angegebene VLAN eingebunden.
Pferdefuß: Die WLAN-Interface fehlen bei der Auswahl der zu überwachenden Interface. Ich gehe mal davon aus, dass die über "Wireless" beim RADIUS angebunden werden sollen.
Dot1x "Server" ist bei MT auch etwas missverständlich beschrieben. Die Verfahren sind identisch nur das .1x Ports dann eben nicht nur die Mac Adresse abgreifen zur Authentisierung sondern vorab per EAPOL die .1x User Credentials abfragt und diese dann identisch wie bei Mac Bypass auf dem Radius Authentisiert. Eine "Server" in dem Sinne ist das nicht.
Vermutlich ist aber der reject-vlan-id Parameter rein eine Funktion bei .1x Portauthentisierung die nicht bei MBP greift.
Im WLAN klappt 802.1x natürlich auch. Das geht im Security Profil über den authentication-types=wpa2-eap. Auf allen Clients ist WPA2-Enterprise per Default aktiv. Siehst du daran das das WLAN dann mit username/password verbindet. Bzw. im Client kann man die konfigurierten Login Credentials oder ein Zertifikat übergeben. Ist in Zeiten dynamisierter Mac Adressen auf Endgeräten manchmal etwas einfacher.
Zumindestens für .1x gibt es dann wohl eine Fallback Option. Ich teste das mal.
Vermutlich ist aber der reject-vlan-id Parameter rein eine Funktion bei .1x Portauthentisierung die nicht bei MBP greift.
Im WLAN klappt 802.1x natürlich auch. Das geht im Security Profil über den authentication-types=wpa2-eap. Auf allen Clients ist WPA2-Enterprise per Default aktiv. Siehst du daran das das WLAN dann mit username/password verbindet. Bzw. im Client kann man die konfigurierten Login Credentials oder ein Zertifikat übergeben. Ist in Zeiten dynamisierter Mac Adressen auf Endgeräten manchmal etwas einfacher.
Zumindestens für .1x gibt es dann wohl eine Fallback Option. Ich teste das mal.
Die Frage ist doch aber, ob der Dot1x-"Server" bei der WLAN-Authentification überhaupt beteiligt ist (und nicht nur der Dot1x-Kern aktiviert über "wpa2-eap"). In der Konfiguration des RADIUS-Clients werden die Quellen ausgewählt, die mit RADIUS geprüft werden sollen. "wireless" wäre aus meiner Sicht der CAPsMAN, "dot1x" der Dot1x-"Server", der sich vordergründig nur um die Ethernet-Ports kümmert. Beim Dot1X gibt es definierte Rückfallebenen, beim CAPsMAN fehlen sie in den Einstellungen zur Access List. Und am zentralen Punkt, dem User-Manager (wo man sie eigentlich erwarten sollte) sind sie, wenn vorhanden, im Manual nicht beschrieben.
Beim Dot1X gibt es noch "virtuelle" Einstellungen beim Interface: "all", "dynamic", "non" und "static". Die beiden letzten Einstellungen halte ich nicht für erfolgversprechend. Mit "all" sperre ich mich vermutlich ganz schnell aus dem System aus, unter "dynamic" könnten allerdings die CAPs fallen, die ja auch bei expliziter Konfiguration erst zur Laufzeit angelegt werden...
Beim Ausprobieren habe ich mich allerdings ganz schnell in den Dot1X-Tiefen verheddert...
Beim Dot1X gibt es noch "virtuelle" Einstellungen beim Interface: "all", "dynamic", "non" und "static". Die beiden letzten Einstellungen halte ich nicht für erfolgversprechend. Mit "all" sperre ich mich vermutlich ganz schnell aus dem System aus, unter "dynamic" könnten allerdings die CAPs fallen, die ja auch bei expliziter Konfiguration erst zur Laufzeit angelegt werden...
Beim Ausprobieren habe ich mich allerdings ganz schnell in den Dot1X-Tiefen verheddert... ob der Dot1x-"Server" bei der WLAN-Authentification überhaupt beteiligt ist
Wenn du nur Mac Bypass machst, also nur Mac Authentisierung dann natürlich nicht. Für Dot1x musst du das WLAN Security Profil auf "WPA2-EAP" stellen (WPA2-Enterprise). Ob mit oder ohne CapsMan ist dabei egal.Dann ist das WLAN an sich immer ein Dot1x WLAN und die Authentisierung passiert dann mit .1x User Credentials. Siehe auch hier:
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Hier ist ein Dot1x Beispiel für Mikrotik:
WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN
Hat mich noch nicht wirklich überzeugt. Im ersten Link geht es um WLAN und hier wird jeweils vom Wireless-Modul der RADIUS direkt abgefragt. Im zweiten geht es um die Ethernet-Schnittstelle, die ja direkt vom Dot1X-Modul verwaltet werden.
Die Konfiguration des RADIUS-Client im MT sieht so aus, dass er für die verschiedenen Module ("wireless", "Dot1X", ...) den Zugang zum RADIUS-Server über spezielle Interface zur Verfügung stellt, die zu oder abgeschaltet werden können.
Daher sieht das für mich so aus, als ob jedes Modul für sich den RADIUS-Server abfragt, CAPsMAN für das WLAN, Dot1X für die Ethernet-Schnittstellen. In diesem Fall obliegt die Reaktion bei Ablehnung nur im jeweiligen Modul: Dot1X stellt dafür spezielle VLAN-Einstellungen zur Verfügung, CAPsMAN leider nicht.
Aber vielleicht leitet CAPsMAN die Abfrage im Fall EAP doch über das Dot1X-Modul um (Interface = dynamic???). Ob das so ist, wird sich wohl nur durch einen Test beweisen lassen. Allerdings wäre die Konfiguration am RADIUS dann schon etwas verwirrend, da ja für WLAN-Nutzer statt "wireless" dann "Dot1X" aktiviert werden müsste...
Die Konfiguration des RADIUS-Client im MT sieht so aus, dass er für die verschiedenen Module ("wireless", "Dot1X", ...) den Zugang zum RADIUS-Server über spezielle Interface zur Verfügung stellt, die zu oder abgeschaltet werden können.
Daher sieht das für mich so aus, als ob jedes Modul für sich den RADIUS-Server abfragt, CAPsMAN für das WLAN, Dot1X für die Ethernet-Schnittstellen. In diesem Fall obliegt die Reaktion bei Ablehnung nur im jeweiligen Modul: Dot1X stellt dafür spezielle VLAN-Einstellungen zur Verfügung, CAPsMAN leider nicht.
Aber vielleicht leitet CAPsMAN die Abfrage im Fall EAP doch über das Dot1X-Modul um (Interface = dynamic???). Ob das so ist, wird sich wohl nur durch einen Test beweisen lassen. Allerdings wäre die Konfiguration am RADIUS dann schon etwas verwirrend, da ja für WLAN-Nutzer statt "wireless" dann "Dot1X" aktiviert werden müsste...
Das ist mehr oder weniger richtig so wie du es sagst. Die 802.1x Funktion im WLAN aktiviert man immer in der Einstellung der WLAN Security auf "WPA2-EAP". Das ist dann WPA2 Enterprise und das erzwingt immer einen Radius Server.
Inwieweit die Haken bei "wireless" oder "dot1x" das im Radius Setting noch beeinflussen müsste man mal testen. Das WLAN Security Setting "WPA2-EAP" erzwingt eigentlich einen Radius so das eigentlich zumindestens der Haken bei Wireless im Radis Setup immer automatisch gesetzt sein sollte. Ich habe bei einem 802.1x WLAN Setup aber noch nie drauf geachtet ob das GUI das dann setzt. Funktionierte auch immer so.
"Dot1x Server" ist ein etwas wirrer Name aber der wird vermutlich nur für Kupfer zuständig sein, denn dann spricht der Port EAPoL Protokoll was es im WLAN ja gar nicht gibt.
Inwieweit die Haken bei "wireless" oder "dot1x" das im Radius Setting noch beeinflussen müsste man mal testen. Das WLAN Security Setting "WPA2-EAP" erzwingt eigentlich einen Radius so das eigentlich zumindestens der Haken bei Wireless im Radis Setup immer automatisch gesetzt sein sollte. Ich habe bei einem 802.1x WLAN Setup aber noch nie drauf geachtet ob das GUI das dann setzt. Funktionierte auch immer so.
"Dot1x Server" ist ein etwas wirrer Name aber der wird vermutlich nur für Kupfer zuständig sein, denn dann spricht der Port EAPoL Protokoll was es im WLAN ja gar nicht gibt.
