25
EAP-TLS mit dem neuen WIFI-Modul unter Mikrotik Router OS 7.14
Hallo miteinander,
ich tüftle schon eine Weile herum, aber ich bekomme EAP-TLS mit dem neuen WIFI-Modul unter RouterOS 7.14 nicht zum Laufen. Als Hardware habe ich den RB5009 sowie den cAP AX.
Ich habe hier und an anderer Stelle einige Anleitungen gefunden - und auch bei Mikrotik selbst findet sich etwas zu EAP-TLS. Das Problem dabei ist, dass sich diese Anleitungen soweit ich das beurteilen kann noch auf das alte "Wireless"-Modul beziehen und sich mit dem neuen WIFI-Modul doch einige Änderungen ergeben haben (z.B.: die Einträge in der Access list sind nicht mehr so möglich, wie das von aqui beschrieben wurde; unter Security gibt es keine Auswahlmöglichkeit "Passthrough" bei TLS-Methods; Ich habe gelesen, dass man die Zertifikate mit secp384r1 und sha384 sollte/muss - aber sha384 kann ich beim Erstellen eines Zertifikats gar nicht auswählen, das ist nur per Terminal-Eingabe möglich; .......)
Ich seht, ein Haufen Probleme.... Ich muss dazu sagen, dass ich nur interessierter Laie bin und das EAP-TLS unter dem "Wireless"-Modul nie ausprobiert habe. Aber ich habe Dot1x/MAB fürs LAN auf meinem ICX6450 unter Verwendung des UserManagers des RB5009 zum Laufen gebracht, etc. etc.
Ich stelle mir halt mittlerweile die Frage ob EAP-TLS unter dem neuen WIFI-Modul überhaupt (schon) funktioniert.
Ich hätte gerne verschiedene Benutzer in verschiedene VLANs geschickt (Laptop, Handy, Tablet unter Verwendung von EAP-TLS ins VLAN10; Kaffeemaschine, Receiver, etc. ohne EAP-TLS ins VLAN 20; usw.). Das alles mit nur einer SSID. Ein Fallback-Gastnetz brauche ich dabei nicht (ist ja mit dem Mikrotik nicht möglich). Sollte überhaupt einmal ein Gast ins WLAN wollen, soll der mir seine MAC geben und darf dann ins (abgetrennte) VLAN99.
Vielleicht kennt Ihr ja eine Anleitung explizit für das neue WIFI-Modul oder könnt mir so den einen oder anderen Fingerzeig geben.
Anbei ein Log. Müsste der Username nicht dem Zertifikatsnamen entsprechen?
ich tüftle schon eine Weile herum, aber ich bekomme EAP-TLS mit dem neuen WIFI-Modul unter RouterOS 7.14 nicht zum Laufen. Als Hardware habe ich den RB5009 sowie den cAP AX.
Ich habe hier und an anderer Stelle einige Anleitungen gefunden - und auch bei Mikrotik selbst findet sich etwas zu EAP-TLS. Das Problem dabei ist, dass sich diese Anleitungen soweit ich das beurteilen kann noch auf das alte "Wireless"-Modul beziehen und sich mit dem neuen WIFI-Modul doch einige Änderungen ergeben haben (z.B.: die Einträge in der Access list sind nicht mehr so möglich, wie das von aqui beschrieben wurde; unter Security gibt es keine Auswahlmöglichkeit "Passthrough" bei TLS-Methods; Ich habe gelesen, dass man die Zertifikate mit secp384r1 und sha384 sollte/muss - aber sha384 kann ich beim Erstellen eines Zertifikats gar nicht auswählen, das ist nur per Terminal-Eingabe möglich; .......)
Ich seht, ein Haufen Probleme.... Ich muss dazu sagen, dass ich nur interessierter Laie bin und das EAP-TLS unter dem "Wireless"-Modul nie ausprobiert habe. Aber ich habe Dot1x/MAB fürs LAN auf meinem ICX6450 unter Verwendung des UserManagers des RB5009 zum Laufen gebracht, etc. etc.
Ich stelle mir halt mittlerweile die Frage ob EAP-TLS unter dem neuen WIFI-Modul überhaupt (schon) funktioniert.
Ich hätte gerne verschiedene Benutzer in verschiedene VLANs geschickt (Laptop, Handy, Tablet unter Verwendung von EAP-TLS ins VLAN10; Kaffeemaschine, Receiver, etc. ohne EAP-TLS ins VLAN 20; usw.). Das alles mit nur einer SSID. Ein Fallback-Gastnetz brauche ich dabei nicht (ist ja mit dem Mikrotik nicht möglich). Sollte überhaupt einmal ein Gast ins WLAN wollen, soll der mir seine MAC geben und darf dann ins (abgetrennte) VLAN99.
Vielleicht kennt Ihr ja eine Anleitung explizit für das neue WIFI-Modul oder könnt mir so den einen oder anderen Fingerzeig geben.
Anbei ein Log. Müsste der Username nicht dem Zertifikatsnamen entsprechen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 51283415647
Url: https://administrator.de/contentid/51283415647
Printed on: June 2, 2024 at 04:06 o'clock
25 Comments
Latest comment
Normalerweise kommt das mit dem klassischen wpa_supplicant Setup beim WLAN Client sofort zum Fliegen.
network={
scan_ssid=1
ssid="xyz"
key_mgmt=IEEE8021X
eap=PEAP
identity="user_name"
password="user_password"
phase2="autheap=MSCHAPV2"
} Müsste der Username nicht dem Zertifikatsnamen entsprechen?
Nein, das hängt immer davon ab ob du die Dot1x Clients klassisch mit Usernamen/Passwort oder mit Client Zertifikaten authorisierst.Bedenke das für EAP-TLS, EAP-TTLS und EAP-PEAP Methoden am Mikrotik Radius Server dort zwingend ein Server Zertifikat benötigt wird. Und zwar auch dann wenn man die Server Zertifikats Abfrage im Client deaktiviert hat.
EAP-MD5, das auch ohne Zertifikat arbeitet, supportet der Mikrotik Usermananger generell nicht! Siehe dazu auch HIER.
Grundlagen zu der Thematik auch hier und den weiterführenden Links dort.
Mit ROS meinte ich Mikrotik RouterOS, sorry. Ich hab's ausgebessert.
Ich habe eine CA erstellt, ein Server- und ein Clientzertifikat. Ich habe mich dabei an die Anleitung von colinardo gehalten: Mikrotik: 802.1X Port basierte Authentifizierung mit Zertifikaten unter RouterOS 7 mit User-Manager als Radius-Server
Damit habe ich Dot1x und MAB im LAN unter Verwendung des Mikrotik Usermanager zum Laufen gebracht.
MAC Authentication im WLAN über den Mikrotik Usermanager läuft auch, aber EAP-TLS will trotz Zertifikaten nicht..
Ich habe eine CA erstellt, ein Server- und ein Clientzertifikat. Ich habe mich dabei an die Anleitung von colinardo gehalten: Mikrotik: 802.1X Port basierte Authentifizierung mit Zertifikaten unter RouterOS 7 mit User-Manager als Radius-Server
Damit habe ich Dot1x und MAB im LAN unter Verwendung des Mikrotik Usermanager zum Laufen gebracht.
MAC Authentication im WLAN über den Mikrotik Usermanager läuft auch, aber EAP-TLS will trotz Zertifikaten nicht..
aber EAP-TLS will trotz Zertifikaten nicht..
Bekommst du es denn testweise mit klassischem User/Passwort hin? Zumindestens damit rennt es in der aktuellen 7.14er fehlerlos so das eher zu vermuten ist das etwas mit dem Client Zertifikats Handling bei dir fehlerhaft ist.
Ehrlich gesagt klappt's nicht einmal mit klassischem User/Passwort..
Ich muss mich irgendwo in den vielen Einstellmöglichkeiten verheddert haben...
Query Radius:
Security:
AAA:
Config:
User Groups:
Wahrscheinlich habe ich irgendwo in den Einstellungen etwas grob falsch gemacht...
Ich nutze den CAPsMAN - ich hoffe, meine Config passt dazu.
Ich habe schon so viel hin und her probiert..
Ich muss mich irgendwo in den vielen Einstellmöglichkeiten verheddert haben...
Query Radius:
Security:
AAA:
Config:
User Groups:
Wahrscheinlich habe ich irgendwo in den Einstellungen etwas grob falsch gemacht...
Ich nutze den CAPsMAN - ich hoffe, meine Config passt dazu.
Ich habe schon so viel hin und her probiert..
Ehrlich gesagt klappt's nicht einmal mit klassischem User/Passwort..
Oha, dann hast du aber schon ein ganz anderes Problem im Unterbau! 🤔Hier als Beispiel mal eine "Quick and Dirty" Konfig damit.
Radius Server und AP sind hier auf getrennten Geräten beide RouterOS 7.14. (Server = CRS Switch (10.1.10.5), AP = hAP ax2 (10.199.1.150))
Table of contents
Setup User Manager (Radius Server)
Wichtig ist hier das Server Zertifikat für die grundsätzliche Funktion des Radius Servers zu erstellen.Hier im Setup auch der Einfachheit halber keine dynamische VLAN Zuweisung.
Die exakte Einrichtung der des User Managers (Mikrotik Radius Server) insbesondere der Zertifikats Generierung kannst du HIER noch einmal genau nachsehen!
Setup Access Point (hAP ax2)
Konfiguration der Radius Server Adresse
Wenn User Manager (Server) und AP (Supplicant) auf dem gleichen physischen Gerät sind, gibt man hier 127.0.0.1 an. Da hier im Setup getrennt, die IP des Radius Servers (User Manager auf CRS Switch)Die Statistiken zeigen hier die gesendeten Radius Requests sowie vom Server empfangenen Accepts und Rejects.
Einrichtung der WPA2-EAP SSID
Der Einfachheit halber hier nur das 2,4 GHz Radio aktiviert.
Log Check bei Client Login (Win 10 Client)
Radius Logging am Server aktiviert, zeigt den positiven Access Accept und die aktive User Session des Clients.Weitere Hinweise zu speziell den Windows Dot1x Clients, wie immer, HIER!
Fazit: Works as designed! 👍 😉
Wow, vielen Dank schon mal!
Ich werde es (leider erst) morgen testen und berichten.
Ich werde es (leider erst) morgen testen und berichten.
Fazit: Works as designed! 👍 😉
Stimmt!!
Und weil's mit Deiner Anleitung so schnell geklappt hat, habe ich EAP-TLS auch ziemlich schnell zum
Laufen gebracht - die Meldungen aus dem Log waren dabei sehr hilfreich. Hier gab es ein paar Probleme mit dem richtigen User-Name.
Meine Feststellungen:
- Mit den von mir erstellten Zertifikaten war alles in Ordnung.
- Mein dümmster Fehler war, dass ich im User-Manager unter Routers nicht das Server-Zertifikat, sondern das CA-Zertifikat hinterlegt habe - so konnte das natürlich per se nichts werden
- Die Einstellungen unter AAA und in der Access List waren überflüssig - oder sogar kontraproduktiv
Jedenfalls habe ich jetzt eine super Grundkonfiguration für mein weiteres Vorgehen.
Nochmals vielen vielen Dank für Deine Hilfe!! Es ist ja auch ein tolles Tutorial draus geworden
1
Glückwunsch! 👏
dass ich im User-Manager unter Routers nicht das Server-Zertifikat, sondern das CA-Zertifikat hinterlegt habe - so konnte das natürlich per se nichts werden
Die genaue Einrichtung per WinBox ist HIER noch einmal nachzulesen.
So, ich habe nun ein paar Client-Zertifikate erstellt und die Android-Geräte per EAP-TLS ins WLAN gebracht. Der Laptop kommt per DOT1X (zumindest mal) ins LAN.
Soweit so gut, aber was mache ich mit einfachen Geräten, die lediglich die Eingabe von SSID und Passwort erlauben. Meine Versuche, die über den User-Manager ins WLAN (VLAN 30) zu bringen schlugen fehl - einen Benutzernamen kann man ja nicht vergeben - und mit der MAC-Adresse ("query radius" in der Access List) bin ich nicht weiter gekommen.. Wobei das mein Favorit gewesen wäre.
Einen Workaround habe ich gefunden - Aktivieren von WPA2 PSK + Passwort + Eintrag in Access List:
Das Problem dabei ist, dass ich dann nichts mehr zentral über den User-Manager einrichten kann.
Und schlimmer: Wenn jemand das WLAN-Passwort errät, landet er im Management VLAN (VLAN 79). Zur Erklärung: der Mikrotik cAP AX hängt tagged in VLAN10, 20, 30, das Management-VLAN (VLAN79) ist untagged. Das sieht nach keiner guten Lösung aus..
Zur Illustration mal ein Log. Bei Eintrag 996 habe ich die oben gezeigte Access List wieder aktivert - der Client wurde dann wieder ins VLAN30 geschoben:
Soweit so gut, aber was mache ich mit einfachen Geräten, die lediglich die Eingabe von SSID und Passwort erlauben. Meine Versuche, die über den User-Manager ins WLAN (VLAN 30) zu bringen schlugen fehl - einen Benutzernamen kann man ja nicht vergeben - und mit der MAC-Adresse ("query radius" in der Access List) bin ich nicht weiter gekommen.. Wobei das mein Favorit gewesen wäre.
Einen Workaround habe ich gefunden - Aktivieren von WPA2 PSK + Passwort + Eintrag in Access List:
Das Problem dabei ist, dass ich dann nichts mehr zentral über den User-Manager einrichten kann.
Und schlimmer: Wenn jemand das WLAN-Passwort errät, landet er im Management VLAN (VLAN 79). Zur Erklärung: der Mikrotik cAP AX hängt tagged in VLAN10, 20, 30, das Management-VLAN (VLAN79) ist untagged. Das sieht nach keiner guten Lösung aus..
Zur Illustration mal ein Log. Bei Eintrag 996 habe ich die oben gezeigte Access List wieder aktivert - der Client wurde dann wieder ins VLAN30 geschoben:
aber was mache ich mit einfachen Geräten, die lediglich die Eingabe von SSID und Passwort erlauben.
Die Endgeräte merken normalerweise durch das entsprechende Beaconing des APs das diese SSID ein WPA2-Enterprise WLAN mit 802.1x ist und wenn du auf "Verbinden" klickst poppt immer automatisch die Username Passwort Abfrage hoch!Bei WLAN Clients die keinen Dot1x fähigen Client onboard haben (Drucker etc.) musst du eine kombinierte Abfrage machen mit Mac und .1x. und den AP so einstellen das wenn Mac (MAB) erfolgreich war KEINE Dot1x Abfrage mehr kommt. Es muss also immer erst MAB und dann .1x kommen!
MAC-Bypass mit Mikrotik und 802.1x Credentials
Puh, ich habe mich eben durch den von Dir verlinkten Thread gekämpft. Da werde ich die nächsten Tage nochmal tüfteln müssen. Ich hatte den Eindruck, dass man da mit Mikrotik-Boardmitteln nicht weiter kommt - oder zumindest damals nicht weiter kam.
Geht man über die Access List??? mit:
Den Wert 00:00:00:00:00:00 frisst er allerdings nur über die Terminaleingabe (dann rote Schrift):
Per Winbox kommt ne Fehlermeldung:
Kommt man dann mit Skip-DOT1X weiter (und mit welchem Wert)?
Naja, wie gesagt, da werde ich noch lesen und tüfteln müssen - aber für heute habe ich eh genug
Geht man über die Access List??? mit:
add mac-address=00:00:00:00:00:00 action=acceptDen Wert 00:00:00:00:00:00 frisst er allerdings nur über die Terminaleingabe (dann rote Schrift):
Per Winbox kommt ne Fehlermeldung:
Kommt man dann mit Skip-DOT1X weiter (und mit welchem Wert)?
Naja, wie gesagt, da werde ich noch lesen und tüfteln müssen - aber für heute habe ich eh genug
Ein äußerst interessanter Artikel - hat mir schon viele nützliche Anregungen geliefert. Leider krieg ich aber trotzdem keine Verbindung hin.
Bei mir geht es allerdings um 802.1x - also WLAN, Wireless, oder wie immer man das nennen mag.
Ich verwende einen Mikrotik RB3011 und verschiedene Access Points (hapAC2, hapAX2), die über CAPsMAN administriert werden. Das funktioniert auch alles allerliebst, nur das mit dem EAP(-TLS) will nicht so recht. Mit dem "alten" wireless Package ging das völlig problemlos - die Zukunft heißt aber wohl wifiwave2 und wenn/falls man auf AX umsteigen will, geht "wireless" sowieso nicht mehr. Soweit zumindest mein Verständnis (-:
Die Radius-Konfiguration scheint auch zu funktionieren.
Ich habe allerdings erst ne Weile mit elliptischen keys rum-experimentiert, das scheint aber in diesem Umfeld gar nicht zu funktionieren. Man bekommt nur ganz dubiose Fehlermeldungen vom User Manager, etwa in dieser Art:
"EAP rejected for user: <some_user_name> ssl: no trusted CA certificate found"
Das ist natürlich völliger Blödsinn, die Zertifikatskette passt. Warum der UM trotzdem kein passendes CA-Zertifikat findet? Keine Ahnung! Ich habe jedenfalls irgendwann mal neue Zertifikate mit RSA-Schlüsseln erstellt und - siehe da - es tut sich was. Leider klappt die Verbindung aber nach wie vor nicht.
Die Fehlerbilder unterscheiden sich nun - je nach verwendetem Access Point.
Als Client verwende ich entweder einen Linux-PC (mit iwd), oder ein Android-Tablet.
Beim hapAX2 ist die Sache ganz seltsam. Es gehen dutzende von EAP-Messages hin und her ... und irgendwann ist einfach Schluss. Keine Fehlermeldung, gar nichts. Manchmal kommt aber auch eine solche Meldung:
manager,debug EAP auth stopped for <some_user_name> reason: timeout + handshake timed out
Das hilft aber auch nicht weiter.
Beim hapAC2 sieht das etwas anders aus - da kommt nach kurzer Zeit diese Fehlermeldung:
wireless,debug 5C:C5:D4:0F:2C:47@cap-wifi4 disassociated, can not assign VLAN, maximum VLAN count for interface reached, signal strength -55
Ich vermute, das liegt daran, dass das Package wifi-qcom-ac nicht mit dynamischen VLAN-Zuweisungen umgehen kann. Zumindest findet man im Mikrotik-Forum Posts, die in diese Richtung deuten.
Das wäre nicht so schlimm, wifi-qcom-ac auf dem hapAC2 ist eh so eine Sache. Da wird es mit dem Speicher schon arg eng und ich musste die Kiste schon mehrfach zurücksetzen, weil man sich nicht mehr einloggen konnte - ohne erkennbaren Grund. Ich vermute, da läuft das Filesystem voll - nach Installation von wifi-qcom-ac liegt der Füllgrad reproduzierbar bei 99%.
Bleibt die Frage, warum das mit den neueren Geräten (hapAX2) nicht funktioniert.
Ich will hier jetzt nicht den kompletten Debug-Output von Radius und UM posten - da steht m.E. nichts verwertbares drin. Die vielen EAP-Packages wären bestimmt interessant, aber das ist zum großen Teil Hex-Code - den kann ich nicht interpretieren.
Im Log des Clients sieht man auch nichts - das sieht regelmäßig so aus:
Nach dem eapSuccess kommt sofort ein tls_reset_handshake.
Habt Ihr vielleicht eine Idee, wie man sowas diagnostiziert?
Ich hab auch schon einen Call beim Mikrotik-Support aufgemacht, da hat in den letzten vier Wochen aber niemand drauf reagiert.
Bei mir geht es allerdings um 802.1x - also WLAN, Wireless, oder wie immer man das nennen mag.
Ich verwende einen Mikrotik RB3011 und verschiedene Access Points (hapAC2, hapAX2), die über CAPsMAN administriert werden. Das funktioniert auch alles allerliebst, nur das mit dem EAP(-TLS) will nicht so recht. Mit dem "alten" wireless Package ging das völlig problemlos - die Zukunft heißt aber wohl wifiwave2 und wenn/falls man auf AX umsteigen will, geht "wireless" sowieso nicht mehr. Soweit zumindest mein Verständnis (-:
Die Radius-Konfiguration scheint auch zu funktionieren.
Ich habe allerdings erst ne Weile mit elliptischen keys rum-experimentiert, das scheint aber in diesem Umfeld gar nicht zu funktionieren. Man bekommt nur ganz dubiose Fehlermeldungen vom User Manager, etwa in dieser Art:
"EAP rejected for user: <some_user_name> ssl: no trusted CA certificate found"
Das ist natürlich völliger Blödsinn, die Zertifikatskette passt. Warum der UM trotzdem kein passendes CA-Zertifikat findet? Keine Ahnung! Ich habe jedenfalls irgendwann mal neue Zertifikate mit RSA-Schlüsseln erstellt und - siehe da - es tut sich was. Leider klappt die Verbindung aber nach wie vor nicht.
Die Fehlerbilder unterscheiden sich nun - je nach verwendetem Access Point.
Als Client verwende ich entweder einen Linux-PC (mit iwd), oder ein Android-Tablet.
Beim hapAX2 ist die Sache ganz seltsam. Es gehen dutzende von EAP-Messages hin und her ... und irgendwann ist einfach Schluss. Keine Fehlermeldung, gar nichts. Manchmal kommt aber auch eine solche Meldung:
manager,debug EAP auth stopped for <some_user_name> reason: timeout + handshake timed out
Das hilft aber auch nicht weiter.
Beim hapAC2 sieht das etwas anders aus - da kommt nach kurzer Zeit diese Fehlermeldung:
wireless,debug 5C:C5:D4:0F:2C:47@cap-wifi4 disassociated, can not assign VLAN, maximum VLAN count for interface reached, signal strength -55
Ich vermute, das liegt daran, dass das Package wifi-qcom-ac nicht mit dynamischen VLAN-Zuweisungen umgehen kann. Zumindest findet man im Mikrotik-Forum Posts, die in diese Richtung deuten.
Das wäre nicht so schlimm, wifi-qcom-ac auf dem hapAC2 ist eh so eine Sache. Da wird es mit dem Speicher schon arg eng und ich musste die Kiste schon mehrfach zurücksetzen, weil man sich nicht mehr einloggen konnte - ohne erkennbaren Grund. Ich vermute, da läuft das Filesystem voll - nach Installation von wifi-qcom-ac liegt der Füllgrad reproduzierbar bei 99%.
Bleibt die Frage, warum das mit den neueren Geräten (hapAX2) nicht funktioniert.
Ich will hier jetzt nicht den kompletten Debug-Output von Radius und UM posten - da steht m.E. nichts verwertbares drin. Die vielen EAP-Packages wären bestimmt interessant, aber das ist zum großen Teil Hex-Code - den kann ich nicht interpretieren.
Im Log des Clients sieht man auch nichts - das sieht regelmäßig so aus:
Mai 17 09:23:57 laptop iwd[592]: event: state, old: disconnected, new: connecting
Mai 17 09:23:57 laptop iwd[592]: TLS: tls_send_client_hello:1381 non-fatal: Local certificate has key type incompatible with cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA's signature algorithm
Mai 17 09:23:57 laptop iwd[592]: TLS: tls_send_client_hello:1381 non-fatal: Local certificate has key type incompatible with cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA's signature algorithm
Mai 17 09:23:57 laptop iwd[592]: TLS: tls_send_client_hello:1381 non-fatal: Local certificate has key type incompatible with cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384's signature algorithm
Mai 17 09:23:57 laptop iwd[592]: TLS: tls_send_client_hello:1381 non-fatal: Local certificate has key type incompatible with cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256's signature algorithm
Mai 17 09:23:57 laptop iwd[592]: TLS: tls_send_client_hello:1381 non-fatal: Local certificate has key type incompatible with cipher suite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA's signature algorithm
Mai 17 09:23:57 laptop iwd[592]: TLS: tls_tx_handshake:1244 Sending a TLS_CLIENT_HELLO of 122 bytes
Mai 17 09:23:57 laptop iwd[592]: TLS: l_tls_start:3610 New state TLS_HANDSHAKE_WAIT_HELLO
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_handshake:3074 Handling a TLS_SERVER_HELLO of 45 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_server_hello:2419 Negotiated TLS 1.2
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_server_hello:2455 Negotiated TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_server_hello:2466 Negotiated CompressionMethod.null
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_server_hello:2492 New state TLS_HANDSHAKE_WAIT_CERTIFICATE
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_handshake:3074 Handling a TLS_CERTIFICATE of 2655 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_certificate:2562 Peer certchain written to /tmp/iwd-tls-debug-server-cert.pem
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_certificate:2666 New state TLS_HANDSHAKE_WAIT_KEY_EXCHANGE
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_handshake:3074 Handling a TLS_SERVER_KEY_EXCHANGE of 585 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_handshake:3172 New state TLS_HANDSHAKE_WAIT_HELLO_DONE
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_ecdhe_server_key_xchg:608 Negotiated secp256r1
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_rsa_verify:240 Peer signature verified
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_ecdhe_server_key_xchg:662 New state TLS_HANDSHAKE_WAIT_HELLO_DONE
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_handshake:3074 Handling a TLS_CERTIFICATE_REQUEST of 25 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_handshake:3074 Handling a TLS_SERVER_HELLO_DONE of 0 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_tx_handshake:1244 Sending a TLS_CERTIFICATE of 1300 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_tx_handshake:1244 Sending a TLS_CLIENT_KEY_EXCHANGE of 66 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_tx_handshake:1244 Sending a TLS_CERTIFICATE_VERIFY of 516 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_tx_handshake:1244 Sending a TLS_FINISHED of 12 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_server_hello_done:2782 New state TLS_HANDSHAKE_WAIT_CHANGE_CIPHER_SPEC
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_message:3449 New state TLS_HANDSHAKE_WAIT_FINISHED
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_handle_handshake:3074 Handling a TLS_FINISHED of 12 bytes
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_reset_handshake:195 New state TLS_HANDSHAKE_WAIT_START
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_finished:3047 New state TLS_HANDSHAKE_DONE
Mai 17 09:23:58 laptop iwd[592]: EAP completed with eapSuccess
Mai 17 09:23:58 laptop iwd[592]: TLS: tls_reset_handshake:195 New state TLS_HANDSHAKE_WAIT_START
Mai 17 09:23:58 laptop iwd[592]: event: state, old: connecting, new: connecting (netconfig)Nach dem eapSuccess kommt sofort ein tls_reset_handshake.
Habt Ihr vielleicht eine Idee, wie man sowas diagnostiziert?
Ich hab auch schon einen Call beim Mikrotik-Support aufgemacht, da hat in den letzten vier Wochen aber niemand drauf reagiert.
Bei mir geht es allerdings um 802.1x - also WLAN, Wireless, oder wie immer man das nennen mag.
Das hast du mit 802.1x oder auch WPA-Enterprise schon richtig benannt! Das andere (reine Mac Authentication) heisst in der Regel MAB (Mac Authentication Bypass).
Die Radius-Konfiguration scheint auch zu funktionieren.
Scheint das nur so oder das wirklich so??Wäre natürlich sehr hilfreich wenn man sowas wasserdicht VORAB an einem LAN oder WLAN Client auch testet!
Ein hiesiges Forentutorial beschreibt ja alle ToDos dafür im Detail mit denen eine fehlerfreies Setup auch für Laien problemlos umsetzbar ist.
die Zertifikatskette passt. Warum der UM trotzdem kein passendes CA-Zertifikat findet? Keine Ahnung!
So aus dem Nichts kommt solche Meldung natürlich auch nicht. Irgendwas läuft da also noch nicht ganz rund bei dir. Ggf. also nochmals alle Schritte zur Erstellung der CA und den Zertifikaten mit dem o.a. Tutorial genau vergleichen!!Meldungen wie "Local certificate has key type incompatible with cipher suite" zeigen auch eher das da was nicht ganz korrekt ist, denn das dürfte so nicht sein.
dass das Package wifi-qcom-ac nicht mit dynamischen VLAN-Zuweisungen umgehen kann.
Das ist aber schon seit Längerem bekannt...Mikrotik Wifiwave2 - CAPsMan VLan Zuordnung
Ggf. helfen auch noch weitere Tutorials:
Konfiguration Cisco AP
Oder alternativ einmal einen RasPi aus der Bastelschublade nehmen und das testweise mit dem FreeRadius im Debug Mode checken der deutlich bessere Debugging Optionen bietet als der Mikrotik Server.
Freeradius Management mit WebGUI
Hi aqui, danke für die schnelle Antwort!
Das muss ich mir mal genauer anschauen - speziell die Sache mit dem Raspberry klingt interessant.
Was die Meldung "Local certificate has key type incompatible with cipher suite" anbelangt, so hab ich die dahingehend interpretiert, dass der iwd alle möglichen cipher suites durchprobiert ... so lange, bis er halt eine findet, die funktioniert. Ist aber nur meine Interpretation - die kann durchaus falsch sein. (-:
Das muss ich mir mal genauer anschauen - speziell die Sache mit dem Raspberry klingt interessant.
Was die Meldung "Local certificate has key type incompatible with cipher suite" anbelangt, so hab ich die dahingehend interpretiert, dass der iwd alle möglichen cipher suites durchprobiert ... so lange, bis er halt eine findet, die funktioniert. Ist aber nur meine Interpretation - die kann durchaus falsch sein. (-:
zum Ausgangsproblem des TO:
Der TO vermengt hier IMO das Feature Access List "query radius" (siehe Screenshots hier: EAP-TLS mit dem neuen WIFI-Modul unter Mikrotik Router OS 7.14) mit der Wifi-Security EAP. Dies führt zu einer doppelten Ansteuerung des Radius und das ist (mindestens) verwirrend.
Das Ziel der MAC-Authentifizierung (und Zuweisung eines VLANs) kann man über das Access List Feature "query radius" erreichen. In der Wifi-Security kann dann einfach bei WPA2-PSK verblieben und im Client das entsprechende Passwort eingetragen werden.
Aus der Doku:
Für ein Gästenetz kann man auch bei der Access List ein spezifisches Passwort mitgeben, das überlagert das in der Wifi-Security vergebene. Ebenso kann dort auch ein VLAN mitgegebenn werden.
Die Access-List sollte bei mehreren SSIDs gegen die SSID gefiltert werden, denn die Wifi-Interfaces verändern sich bei dynamischer Konfiguration über den CAPsMAN. Im Falle des TO filtert man natürlich direkt auf die MAC-Adressen.
Eleganter ist sicher der Weg über direktes EAP - dann aber ohne das Access List - Feature. Ob das sauber funktioniert, kann ich noch nicht sagen.
Viele Grüße, commodity
Viele Grüße, commodity
Der TO vermengt hier IMO das Feature Access List "query radius" (siehe Screenshots hier: EAP-TLS mit dem neuen WIFI-Modul unter Mikrotik Router OS 7.14) mit der Wifi-Security EAP. Dies führt zu einer doppelten Ansteuerung des Radius und das ist (mindestens) verwirrend.
Das Ziel der MAC-Authentifizierung (und Zuweisung eines VLANs) kann man über das Access List Feature "query radius" erreichen. In der Wifi-Security kann dann einfach bei WPA2-PSK verblieben und im Client das entsprechende Passwort eingetragen werden.
Aus der Doku:
When a client device tries to associate with an AP, which is configured to perform MAC address authentication, the AP will send an access-request message to a RADIUS server with the device's MAC address as the user name and an empty password. If the RADIUS server answers with access-accept to such a request, the AP proceeds with whatever regular authentication procedure (passphrase or EAP authentication) is configured for the interface.
Wichtig ist der letzte Satz: Nach der erfolgreichen Authentifizierung der MAC durch den RADIUS werden noch die in der Security eingetragenen Zugangsdaten abgefragt.Für ein Gästenetz kann man auch bei der Access List ein spezifisches Passwort mitgeben, das überlagert das in der Wifi-Security vergebene. Ebenso kann dort auch ein VLAN mitgegebenn werden.
Die Access-List sollte bei mehreren SSIDs gegen die SSID gefiltert werden, denn die Wifi-Interfaces verändern sich bei dynamischer Konfiguration über den CAPsMAN. Im Falle des TO filtert man natürlich direkt auf die MAC-Adressen.
Eleganter ist sicher der Weg über direktes EAP - dann aber ohne das Access List - Feature. Ob das sauber funktioniert, kann ich noch nicht sagen.
Viele Grüße, commodity
Viele Grüße, commodity
1Scheint das nur so oder das wirklich so??
Wäre natürlich sehr hilfreich wenn man sowas wasserdicht VORAB an einem LAN oder WLAN Client auch testet!
Ein hiesiges Forentutorial beschreibt ja alle ToDos dafür im Detail mit denen eine fehlerfreies Setup auch für Laien problemlos umsetzbar ist.
Wäre natürlich sehr hilfreich wenn man sowas wasserdicht VORAB an einem LAN oder WLAN Client auch testet!
Ein hiesiges Forentutorial beschreibt ja alle ToDos dafür im Detail mit denen eine fehlerfreies Setup auch für Laien problemlos umsetzbar ist.
So ... ich hab das mal mit einem Raspberry und einer Kabelverbindung getestet. Klappt ganz hervorragend, auch mit dynamischen VLANs und sogar mit elliptischen Keys - jetzt muss ich nur noch das kabellose Zeug zum Laufen kriegen ... paar Ideen hab ich schon. Das kann doch nicht so schwer sein!
Hier mal eine Version wenn man mit dem aktuellen RasPi OS den Network Manager nutzt.
Connectionprofil einfach unter /etc/NetworkManager/sysconnections mit dem Editor anpassen
Connectionprofil einfach unter /etc/NetworkManager/sysconnections mit dem Editor anpassen
Version mit statischem Username Passwort:
[connection]
id=USB-Adapter
uuid=538c2100-2175-319a-a857-a3baae31890f
type=ethernet
interface-name=eth1
[ethernet]
[802-1x]
eap=tls;
identity=zero2w
password=zero2w
phase2-auth=mschapv2
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy] Version mit .p12 Zertifikaten
[connection]
id=USB-Adapter
uuid=538c2100-2175-319a-a857-a3baae31890f
type=ethernet
interface-name=eth1
[ethernet]
[802-1x]
eap=tls;
identity=zero2w
ca-cert=/home/user/.certs/MeineCA.crt
client-cert=/home/user/.certs/zero2w.p12
private-key=/home/user/.certs/zero2w.p12
private-key-password=test1234
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
Danke für Deine Tipps!
Dummer Weise verwende ich keinen Network Manager. Ich bin schon vor einigen Jahren auf systemd-networkd umgestiegen ... aus vielerlei Gründen.
Der systemd-networkd kann per se keine wireless Verbindungen aufbauen, da braucht's einen entsprechenden Service, der sich dann wieder eines Hilfsprogramms (wpa_supplicant, iwd) bedient. Alles kein Hexenwerk, allerdings scheint mein Favorit (der iwd) mit dem 6.6er Kernel so seine Probleme zu haben.
Also nehmen wir wpa_supplicant:
cat /etc/wpa_supplicant/wpa_supplicant_wlan0.conf
eapol_version=2
network={
ssid="WPA2_EAP_2_ax"
key_mgmt=WPA-EAP
eap=TLS
identity="klaus@##########"
private_key="/home/klaus/cert_export_klaus@##########.p12"
private_key_passwd="ein_passwort"
eapol_flags=0
}
wpa_supplicant -D nl80211 -c /etc/wpa_supplicant/wpa_supplicant_wlan0.conf -i wlan0
Successfully initialized wpa_supplicant
wlan0: Trying to associate with 48:a9:8a:b7:3b:97 (SSID='WPA2_EAP_2_ax' freq=2412 MHz)
wlan0: Associated with 48:a9:8a:b7:3b:97
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/CN=RADIUS_CA' hash=3e35a7ed10244cd80417f51c77e16ec349499b2ec9d28024bf687f14ec5a34ac
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/CN=RADIUS_CA' hash=3e35a7ed10244cd80417f51c77e16ec349499b2ec9d28024bf687f14ec5a34ac
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/CN=USERMAN_CERT' hash=5a172ce67277e67711958a54fbfad6b73faefd5364a93d76f31b74897b9b762b
wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius.########.de
wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlan0: CTRL-EVENT-CONNECTED - Connection to 48:a9:8a:b7:3b:97 completed [id=0 id_str=]
Das sieht schon sehr schön aus!
Leider bekomme ich aber keine IP-Adresse )-:
Bevor Ihr fragt - der DHCP-Server läuft und funktioniert auch und die VLANs sind in der Bridge den wifi-Interfaces zugeordnet. An der Stelle frage ich mich allerdings, ob das sinnvoll ist. Die Namen der Devices werden ja vom CAPsMAN (dynamisch) vergeben - was ist, wenn der sich mal irgendwann andere Namen ausdenkt?
Leider kriege ich die DHCP-Server nicht dazu, irgendwelche (verwertbaren) Angaben ins Log zu schreiben.
/system/logging/add dhcp,debug
hilft jedenfalls nichts.
Ich hab's dann mal mit festen IPs probiert, das funktioniert auch nicht ... und da läuft man dann in ein Problem des Raspberry mit dem Broadcom WiFi driver (CTRL-EVENT-ASSOC-REJECT status_code=16). Ich will das jetzt nicht weiter ausführen, wer will, kann das hier nachlesen:
https://raspberrypi.stackexchange.com/questions/77144/rpi3-wireless-issu ...
Summa summarum: es bleibt spannend
Dummer Weise verwende ich keinen Network Manager. Ich bin schon vor einigen Jahren auf systemd-networkd umgestiegen ... aus vielerlei Gründen.
Der systemd-networkd kann per se keine wireless Verbindungen aufbauen, da braucht's einen entsprechenden Service, der sich dann wieder eines Hilfsprogramms (wpa_supplicant, iwd) bedient. Alles kein Hexenwerk, allerdings scheint mein Favorit (der iwd) mit dem 6.6er Kernel so seine Probleme zu haben.
Also nehmen wir wpa_supplicant:
cat /etc/wpa_supplicant/wpa_supplicant_wlan0.conf
eapol_version=2
network={
ssid="WPA2_EAP_2_ax"
key_mgmt=WPA-EAP
eap=TLS
identity="klaus@##########"
private_key="/home/klaus/cert_export_klaus@##########.p12"
private_key_passwd="ein_passwort"
eapol_flags=0
}
wpa_supplicant -D nl80211 -c /etc/wpa_supplicant/wpa_supplicant_wlan0.conf -i wlan0
Successfully initialized wpa_supplicant
wlan0: Trying to associate with 48:a9:8a:b7:3b:97 (SSID='WPA2_EAP_2_ax' freq=2412 MHz)
wlan0: Associated with 48:a9:8a:b7:3b:97
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/CN=RADIUS_CA' hash=3e35a7ed10244cd80417f51c77e16ec349499b2ec9d28024bf687f14ec5a34ac
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/CN=RADIUS_CA' hash=3e35a7ed10244cd80417f51c77e16ec349499b2ec9d28024bf687f14ec5a34ac
wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/CN=USERMAN_CERT' hash=5a172ce67277e67711958a54fbfad6b73faefd5364a93d76f31b74897b9b762b
wlan0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:radius.########.de
wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlan0: CTRL-EVENT-CONNECTED - Connection to 48:a9:8a:b7:3b:97 completed [id=0 id_str=]
Das sieht schon sehr schön aus!
Leider bekomme ich aber keine IP-Adresse )-:
Bevor Ihr fragt - der DHCP-Server läuft und funktioniert auch und die VLANs sind in der Bridge den wifi-Interfaces zugeordnet. An der Stelle frage ich mich allerdings, ob das sinnvoll ist. Die Namen der Devices werden ja vom CAPsMAN (dynamisch) vergeben - was ist, wenn der sich mal irgendwann andere Namen ausdenkt?
Leider kriege ich die DHCP-Server nicht dazu, irgendwelche (verwertbaren) Angaben ins Log zu schreiben.
/system/logging/add dhcp,debug
hilft jedenfalls nichts.
Ich hab's dann mal mit festen IPs probiert, das funktioniert auch nicht ... und da läuft man dann in ein Problem des Raspberry mit dem Broadcom WiFi driver (CTRL-EVENT-ASSOC-REJECT status_code=16). Ich will das jetzt nicht weiter ausführen, wer will, kann das hier nachlesen:
https://raspberrypi.stackexchange.com/questions/77144/rpi3-wireless-issu ...
Summa summarum: es bleibt spannend
Dummer Weise verwende ich keinen Network Manager.
Das ist auch vollkommen Wumpe... Es klappt immer, egal ob man systemd, NetworkManager oder WPA-Supplicant nutzt.Nur du sagtest das du mit einem Raspberry testest und zumindestens mit dessen aktuellem Bookworm Image ist der NetworkManager im Default aktiv und nicht mehr wählbar wie unter Bullseye.
Daher für dich die "RasPi" Lösung mit Network Manager. 😉
Leider bekomme ich aber keine IP-Adresse
Das zeigt das die interne Anbindung der WLAN Interfaces an die VLAN Bridge (sofern du mit VLANs arbeitest?!) falsch oder fehlerhaft ist.Dann scheitert die Layer 2 Connection und der WLAN Client "sieht" keinen DHCP Server.
Ohne aber dein genaues Setup zu kennen muss man im freien Fall Kristallkugeln...
dann mal mit festen IPs probiert, das funktioniert auch nicht
Spricht deutlich für den Verdacht das an der Layer 2 Anbindung der WLAN Radio Interfaces an die VLANs etwas grundsätzlich schief gelaufen ist!Tip:
Gehe strategisch vor und konfiguriere dir das WLAN erstmal offen oder mit statischen Keys und checke erstmal die WLAN Verbindung an sich das die wasserdicht mit IP Vergabe und IP Connectivity rennt.
Wenn das der Fall ist stellst du nur die Security auf WPA-Enterprise um und fertisch...
Nur du sagtest das du mit einem Raspberry testest und zumindestens mit dessen aktuellem Bookworm Image ist der NetworkManager im Default aktiv und nicht mehr wählbar wie unter Bullseye.
ach ... wählen kann man immer, das ist sogar ein Bookworm, was da läuft - aber halt von Bullseye upgegradet (auch, wenn das offiziell ja gar nicht geht bzw. erlaubt ist)
Soweit ich weiß, ist der NetworkManager doch auch nur ein Service, der vom systemd gestartet wird.
Egal, zurück zum Thema:
Dann scheitert die Layer 2 Connection und der WLAN Client "sieht" keinen DHCP Server.
Sowas hab ich mir schon gedacht, kann's aber halt nicht so fachmännich ausdrücken.Ich kann Dir gerne mal nen Blick in die Kristallkugel verschaffen.
Weil die Config aber halt schon recht umfangreich ist, wollte ich das nicht hier alles rein-spammen.
Vielleicht ein Auszug?
Welchen Teil brauchst Du?
- Interfaces (Ethernet, VLAN,Bridge, Wifi)
- der ganze DHCP-Kram ?
- die CAPsMAN-Sachen?
... und zum Schluß ne ganz blöde Frage - wie macht man denn ein offenes WLAN?
Soweit ich weiß, ist der NetworkManager doch auch nur ein Service, der vom systemd gestartet wird.
So ist es! Welchen Teil brauchst Du?
Vergleiche es zuallererst einmal mit dem Mikrotik VLAN Tutorial ob deine Settings da übereinstimmen und alles richtig umgesetzt ist.Relevant ist primär die VLAN Bridge mit Memberports und VLANs ob die physischen WiFi Interfaces dort eingehängt sind. Das bestimmt letztlich die Connectivity und das Binding auf die VLAN IP Adressen.
und zum Schluß ne ganz blöde Frage - wie macht man denn ein offenes WLAN?
Blöde Fragen jibbet doch nich nur blöde....du weisst schon! 
Einfach die Security weglassen. Damit hast du dann ein offenes, unverschlüsseltes WLAN. Einfach nur verbinden klicken und fertisch...
Das ist das was man in der Regel aufsetzt wenn man ein Gäste Captive Portal betreibt. Allen Gästen ein Passwort frei zu verraten wäre ja ziemlich sinnfrei. Nach einer Woche kennt das ja so oder so jederman.
sooo ... hat bissl gedauert.
Ich hab den ganzen Kram (RB3011 und hapAX2) neu aufgesetzt, weil da irgendwas überhaupt nicht gepasst hat. Das DHCP hat nicht mal an den Kabel-Ports des hapAX2 funktioniert ... und Fehler in der Konfiguration konnte ich keine finden
Recht gewöhnungsbedürftig fand ich jedoch, dass man die Wifi-Interfaces auf dem hapAX2 in die Bridge hängen muss. Wenn man sich die Mikrotik-Doku durchliest, so könnte man zu dem Schluss kommen, dass der CAPsMAN die Interfaces komplett steuert, die Konfiguration also über die (zentrale) Bridge auf dem RB3011 stattfindet (configuration.manager=capsman) . Dem ist aber offensichtlich nicht so.
Jetzt funktioniert das wieder und - Überraschung! - auch das DHCP an den Wireless Ports funktioniert.
Sogar die Authentifizierung mit EAP-TLS funktioniert.
AAABER:
es wird immer das VLAN zugewiesen, das beim Bridge-Port eingetragen ist,
also das, was bei
/interface bridge port add bridge=local-bridge interface=wlan1 pvid=80
angegeben wurde.
Das, was bei den VLANs steht, wird vollkommen ignoriert:
/interface bridge vlan add bridge=local-bridge tagged=local-bridge,ether1,wlan1,wlan2 vlan-ids=40
/interface bridge vlan add bridge=local-bridge tagged=local-bridge,ether1,wlan1,wlan2 vlan-ids=50
z.B:
Wenn ich nun einen User anlege:
und mich mit diesem User anmelde, dann wird der Session eine IP aus dem Pool mit der PVID=80 zugewiesen - obwohl doch Tunnel-Private-Group-ID:50 verlangt wird. Wenn ich eine PVID eintrage, für die kein DHCP-Server existiert (z.B. PVID=1), dann gibt's auch keine IP
Man sieht, dass der Wunsch nach einer ganz bestimmten VLAN-ID beim User-Manager ankommt:
... es hat aber leider keine Auswirkung.
Damit ist natürlich keine dynamische VLAN-Zuweisung möglich.
Ich hab dann noch ne Weile rum-experimentiert und bin - mehr durch Zufall - auf die Lösung gekommen.
Irgendwo hab' ich mal gelesen, dass manche Access Points (welche genau das sind, habe ich vergessen) darauf stehen, dass zusätzlich das Attribut Mikrotik-Wireless-VLANID angegeben wird. Siehe da, wenn man das so macht, funktioniert's:
Das war doch gar nicht so schwer
Ich hab den ganzen Kram (RB3011 und hapAX2) neu aufgesetzt, weil da irgendwas überhaupt nicht gepasst hat. Das DHCP hat nicht mal an den Kabel-Ports des hapAX2 funktioniert ... und Fehler in der Konfiguration konnte ich keine finden
Recht gewöhnungsbedürftig fand ich jedoch, dass man die Wifi-Interfaces auf dem hapAX2 in die Bridge hängen muss. Wenn man sich die Mikrotik-Doku durchliest, so könnte man zu dem Schluss kommen, dass der CAPsMAN die Interfaces komplett steuert, die Konfiguration also über die (zentrale) Bridge auf dem RB3011 stattfindet (configuration.manager=capsman) . Dem ist aber offensichtlich nicht so.
Jetzt funktioniert das wieder und - Überraschung! - auch das DHCP an den Wireless Ports funktioniert.
Sogar die Authentifizierung mit EAP-TLS funktioniert.
AAABER:
es wird immer das VLAN zugewiesen, das beim Bridge-Port eingetragen ist,
also das, was bei
/interface bridge port add bridge=local-bridge interface=wlan1 pvid=80
angegeben wurde.
Das, was bei den VLANs steht, wird vollkommen ignoriert:
/interface bridge vlan add bridge=local-bridge tagged=local-bridge,ether1,wlan1,wlan2 vlan-ids=40
/interface bridge vlan add bridge=local-bridge tagged=local-bridge,ether1,wlan1,wlan2 vlan-ids=50
z.B:
/interface/bridge/port pri
Flags: I - INACTIVE
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HORIZON
# INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON
...
15 wlan1 local-bridge 80 0x80 none
16 wlan2 local-bridge 80 0x80 none/interface/bridge/vlan pri
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
# BRIDGE VLAN-IDS CURRENT-TAGGED CURRENT-UNTAGGED
...
1 local-bridge 40 local-bridge
ether1
wlan1
wlan2
2 local-bridge 50 local-bridge
ether1
wlan1
wlan2Wenn ich nun einen User anlege:
/user-manager user group add attributes=Tunnel-Type:13,Tunnel-Medium-Type:6,Tunnel-Private-Group-ID:50 name=certificate-authenticated outer-auths=eap-tls
/user-manager user add group=eap-tls-auth name=klaus@.########.deund mich mit diesem User anmelde, dann wird der Session eine IP aus dem Pool mit der PVID=80 zugewiesen - obwohl doch Tunnel-Private-Group-ID:50 verlangt wird. Wenn ich eine PVID eintrage, für die kein DHCP-Server existiert (z.B. PVID=1), dann gibt's auch keine IP
Man sieht, dass der Wunsch nach einer ganz bestimmten VLAN-ID beim User-Manager ankommt:
14:56:22 radius,debug,packet Tunnel-Type = 13
14:56:22 radius,debug,packet Tunnel-Medium-Type = 6
14:56:22 radius,debug,packet Tunnel-Private-Group-ID = "50" ... es hat aber leider keine Auswirkung.
Damit ist natürlich keine dynamische VLAN-Zuweisung möglich.
Ich hab dann noch ne Weile rum-experimentiert und bin - mehr durch Zufall - auf die Lösung gekommen.
Irgendwo hab' ich mal gelesen, dass manche Access Points (welche genau das sind, habe ich vergessen) darauf stehen, dass zusätzlich das Attribut Mikrotik-Wireless-VLANID angegeben wird. Siehe da, wenn man das so macht, funktioniert's:
/user-manager user group add attributes=Tunnel-Type:13,Tunnel-Medium-Type:6,Tunnel-Private-Group-ID:50,Mikrotik-Wireless-VLANID:50 name=certificate-authenticated outer-auths=eap-tls
/user-manager user add group=eap-tls-auth name=klaus@.########.deDas war doch gar nicht so schwer
dass zusätzlich das Attribut Mikrotik-Wireless-VLANID angegeben wird.
Das ist aber hinreichend bekannt und steht hier auch in allen möglichen Mikrtoik Tutorials drin das MT zu mindestens bei Wireless dort eigene Radius Attribute nutzt. (Gilt nicht für Kupferports!)Man muss also nur einmal genau lesen dann ist die Lösung nicht nur vom Zufall abhängig!!
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN
Mikrotik: Wifi clients in anderes VLAN schieben?
und und und...
Lesen hilft also wirklich!
Aber klasse das nun alles rennt wie es soll! 👍
Zeigt dann auch das dyn. VLANs mit CapsMan sauber laufen.
ja ... lesen bildet (-:
Gelesen hab ich schon Vieles - aber dann offensichtlich halt nicht wirklich verstanden.
Bin eigentlich eher in der Welt der Datenbanken (Oracle) zuhause und hab mit dem Netzwerk-Zeug noch so meine Probleme.
Danke nochmals für Deine Unterstützung - ohne die hätte ich das wohl kaum geschafft.
Die Mikrotik-Doku ist ... irgendwie ... nicht so der Hit. Da, wo's interessant wird/würde, hört's immer auf
Oder ich bin einfach zu dämlich?
Egal - Hauptsache, es geht!
Gelesen hab ich schon Vieles - aber dann offensichtlich halt nicht wirklich verstanden.
Bin eigentlich eher in der Welt der Datenbanken (Oracle) zuhause und hab mit dem Netzwerk-Zeug noch so meine Probleme.
Danke nochmals für Deine Unterstützung - ohne die hätte ich das wohl kaum geschafft.
Die Mikrotik-Doku ist ... irgendwie ... nicht so der Hit. Da, wo's interessant wird/würde, hört's immer auf
Oder ich bin einfach zu dämlich?
Egal - Hauptsache, es geht!
Egal - Hauptsache, es geht!
So ist es und nicht zu vergessen hast DU das gewuppt bekommen. Dein "Netzwerk-Zeug" Wissen ist sicher im 98% gestiegen!Fazit: Alles richtig gemacht!