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).
Please also mark the comments that contributed to the solution of the article
Content-ID: 5257372514
Url: https://administrator.de/contentid/5257372514
Printed on: November 11, 2024 at 19:11 o'clock
17 Comments
Latest comment
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! 😉
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.
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.
Wird korrigiert.
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?!
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 "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.
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
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.