marple
Goto Top

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?

screenshot 2024-03-08 103827

Content-Key: 51283415647

Url: https://administrator.de/contentid/51283415647

Printed on: May 28, 2024 at 07:05 o'clock

Member: aqui
aqui Mar 08, 2024 updated at 10:20:44 (UTC)
Goto Top
Mit "ROS" meinst du Raspberry OS, also quasi ein stinknormales, Debian basiertes Linux? 🤔
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"
} 
Windows und Apple Clients arbeiten per se problemlos.
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.
Member: Marple
Marple Mar 08, 2024 at 10:38:23 (UTC)
Goto Top
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..
Member: aqui
aqui Mar 08, 2024 at 11:13:00 (UTC)
Goto Top
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.
Member: Marple
Marple Mar 08, 2024 updated at 12:16:22 (UTC)
Goto Top
Ehrlich gesagt klappt's nicht einmal mit klassischem User/Passwort..
Ich muss mich irgendwo in den vielen Einstellmöglichkeiten verheddert haben...

Query Radius:
screenshot 2024-03-08 124439

Security:
screenshot 2024-03-08 125317
screenshot 2024-03-08 124701

screenshot 2024-03-08 124714

AAA:
screenshot 2024-03-08 124532

Config:
screenshot 2024-03-08 124807


User Groups:

screenshot 2024-03-08 130236


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..
screenshot 2024-03-08 130124
screenshot 2024-03-08 124513
screenshot 2024-03-08 124643
Member: aqui
Solution aqui Mar 08, 2024, updated at Mar 09, 2024 at 12:30:22 (UTC)
Goto Top
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))


back-to-topSetup 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!

dot1xusermanager

back-to-topSetup Access Point (hAP ax2)


back-to-topKonfiguration 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.
dot1xradius

back-to-topEinrichtung der WPA2-EAP SSID

Der Einfachheit halber hier nur das 2,4 GHz Radio aktiviert.
dot1xssid

back-to-topLog 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!
dot1xcheck

Fazit: Works as designed! 👍 😉
Member: Marple
Marple Mar 08, 2024 at 16:30:19 (UTC)
Goto Top
Wow, vielen Dank schon mal!
Ich werde es (leider erst) morgen testen und berichten.
Member: Marple
Solution Marple Mar 09, 2024 at 11:24:56 (UTC)
Goto Top
Fazit: Works as designed! 👍 😉


Stimmt!! face-wink
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
Member: aqui
aqui Mar 09, 2024 at 12:32:19 (UTC)
Goto Top
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. face-wink
Member: Marple
Marple Mar 10, 2024 updated at 13:26:55 (UTC)
Goto Top
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:

security

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:

vlans
Member: aqui
aqui Mar 10, 2024 updated at 14:26:17 (UTC)
Goto Top
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
Member: Marple
Marple Mar 10, 2024 updated at 17:55:23 (UTC)
Goto Top
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:
add mac-address=00:00:00:00:00:00 action=accept

Den Wert 00:00:00:00:00:00 frisst er allerdings nur über die Terminaleingabe (dann rote Schrift):
rot

Per Winbox kommt ne Fehlermeldung:
fehler

Kommt man dann mit Skip-DOT1X weiter (und mit welchem Wert)?
skip

Naja, wie gesagt, da werde ich noch lesen und tüfteln müssen - aber für heute habe ich eh genug face-wink
Member: rapkin
rapkin May 18, 2024 at 14:56:53 (UTC)
Goto Top
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:

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.
Member: aqui
aqui May 18, 2024 updated at 15:44:59 (UTC)
Goto Top
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! face-wink
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
Member: rapkin
rapkin May 18, 2024 at 18:06:10 (UTC)
Goto Top
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. (-:
Member: commodity
commodity May 19, 2024 at 13:17:54 (UTC)
Goto Top
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:
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
Member: rapkin
rapkin May 21, 2024 at 15:05:54 (UTC)
Goto Top
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.

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!
Member: aqui
aqui May 21, 2024 updated at 16:13:27 (UTC)
Goto Top
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

back-to-topVersion 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] 


back-to-topVersion 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] 
Member: rapkin
rapkin May 24, 2024 at 10:10:38 (UTC)
Goto Top
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
Member: aqui
aqui May 24, 2024 updated at 12:49:27 (UTC)
Goto Top
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... face-sad
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...
Member: rapkin
rapkin May 24, 2024 at 13:28:57 (UTC)
Goto Top
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) face-smile
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?
Member: aqui
aqui May 24, 2024 updated at 16:18:07 (UTC)
Goto Top
Soweit ich weiß, ist der NetworkManager doch auch nur ein Service, der vom systemd gestartet wird.
So ist es! face-wink
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! face-big-smile
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. face-wink