07.06.2020, aktualisiert am 31.05.2024 um 14:27:41 Uhr

32664

Mikrotik: 802.1X Port basierte Authentifizierung mit Zertifikaten unter RouterOS 7 mit User-Manager als Radius-Server

Einleitung

Die folgende Anleitung soll als eine zusätzliche Ergänzung zu der schon bestehenden hervorragenden Übersicht von @aqui in der Anleitung Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik dienen, und die Möglichkeiten des User-Managers vorstellen der als bislang in RouterOS 6 als "abgespeckter" Radius-Server sein Dasein pflichtete. Mit den neuen Möglichkeiten wird der User-Manager endlich auch zu einem echten Radius-Server den man auch zur Authentifizierung zusätzlich zu PAP, CHAP, MS-CHAP, MS-CHAPv2 über die gängigen EAP-Methoden EAP-TLS, EAP-TTLS and EAP-PEAP nutzen kann, damit wächst der User-Manager zu einem, zwar nicht einem freeradius ebenbürtigen Kandidaten heran, aber in Zukunft kann man auch für einige Setups auf einen separaten Radius-Server verzichten.

Ich greife hier schon etwas der aktuellen Entwicklung von RouterOS im produktiven 6er Zweig voraus und möchte den neuen User-Manger im aktuellen Release von RouterOS 7 im Zusammenspiel mit 802.1X Port basierter Authentifizierung vorstellen. Da in @aqui 's Anleitung schon die dynamische VLAN Zuweisung für WLAN-Clients behandelt wurde, greife ich hier die in RouterOS enthaltene 802.1x Port basierte Authentifizierung auf.

Die Anleitung funktioniert ausdrücklich nicht auf dem 6er Zweig von RouterOS.

Hinweise

Für den User-Manager wird es in Zukunft auch kein extra Web-Administrationsportal mehr geben und die Verwaltung wird in Winbox und in das reguläre Konfigurationswebinterface eingepflegt. Da es zum Zeitpunkt des Verfassens dieser Anleitung noch keine User-Manager GUI gab beschränke ich mich hier vornehmlich auf die Konfiguration über die Konsole.
Das User-Manager Paket ist ein separates Package zu finden unter "Extra packages" unter https://mikrotik.com/download. Das *.npk extrahiert man und zieht es entweder per Drag n' Drop in Winbox auf den Router, oder überträgt es per (S)-FTP in das Root Verzeichnis des Mikrotik. Nach einem obligatorischen Reboot steht der User-Manager zur Verfügung.

1. Radius Client erstellen

Damit der Mikrotik Radius-Anfragen an den User-Manager schicken und empfangen kann legen wir einen entsprechenden Eintrag wie folgt an:

/radius add address=127.0.0.1 secret=Passw0rd service=dot1x src-address=127.0.0.1

Da der User-Manager hier auf dem gleichen Mikrotik läuft reicht hier die Loopback Adresse. Das Passwort kann natürlich frei gewählt werden, muss aber dann mit dem im User-Manager angelegten Passwort (unter Punkt 5) identisch sein.

2. Interface für 802.1X Authentifizierung vorbereiten

/interface dot1x server add interface=ether2 disabled=yes

Hinter interface= geben wir den Port an welchen wir mit 802.1x schützen möchten. Vorerst deaktivieren wir den Eintrag noch (disabled=yes) da sonst die Verbindung zum Client gekappt wird. Zum späteren Zeitpunkt aktivieren wir den Eintrag dann (Punkt 6).

3. Zertifikate erstellen

Die Anleitung soll jetzt nicht erneut die Grundlagen über die Erstellung von Zertifikaten behandeln, dafür existieren genügend ausführliche Anleitungen im Netz. Für das Beispiel generieren wir hier der Einfachheit halber eine Zertifizierungsstelle,Server- und Client-Zertifikat direkt auf dem Mikrotik.
Unsere CA nennen wir im Beispiel DOT1X_CA, den Common-Name des Server-Zertifikats DOT1X_SERVER und den des Clients DOT1X_CLIENT1.

3.1 CA Zertifikat erstellen und signieren

/certificate add name=DOT1X_CA common-name=DOT1X_CA days-valid=7300 trusted=yes country=DE
/certificate sign DOT1X_CA

3.2 Server Zertifikat erstellen und signieren

/certificate add common-name=DOT1X_SERVER days-valid=730 country=DE key-usage=tls-server,tls-client,digital-signature,key-encipherment
/certificate sign DOT1X_SERVER ca=DOT1X_CA

3.3 Client Zertifikat erstellen und signieren

/certificate add common-name=DOT1X_CLIENT1 days-valid=730 country=DE key-usage=tls-client,digital-signature,key-encipherment
/certificate sign DOT1X_CLIENT1 ca=DOT1X_CA

4. Zertifikate für die Verwendung am Client exportieren

Das Zertifikat der Zertifizierungsstelle (CA) exportieren wir als *.crt

/certificate export-certificate DOT1X_CA

Und das Client Zertifikat mit dessen privatem Schlüssel als *.p12 pkcs12 Container

/certificate export-certificate DOT1X_CLIENT1 export-passphrase=Passw0rd type=pkcs12

Die Zertifikate werden im lokalen Speicher des Mikrotik abgelegt. Von dort aus kopiert man sie auf den Client. Unter Windows via Winbox entweder per Drag n' Drop auf den Desktop/Ordner ziehen oder per S-FTP oder FTP am Mikrotik einloggen und übertragen.

5. User-Manager einrichten

Dieser Schritt besteht hauptsächlich aus folgenden Schritten:

Router-Objekt anlegen (Authenticator festlegen)
Zu nutzendes Server Zertifikat festlegen
Profil anlegen(definieren von Limits usw.)
Authentifizierungs-Variante für EAP-TLS erstellen
User anlegen
User dem Profil zuweisen.

Die Schritte fasse ich hier als Konsolenbefehle zusammen, Passwort und Namen der Zertifikate müssen angepasst werden wenn oben dafür andere Werte verwendet wurden:

/user-manager router add address=127.0.0.1 name=localrouter shared-secret=Passw0rd
/user-manager set certificate=DOT1X_SERVER enabled=yes
/user-manager user group add name=dot1x-tls-auth outer-auths=eap-tls
/user-manager user add name=DOT1X_CLIENT1 group=dot1x-tls-auth

6. 802.1X am Mikrotik für das Interface aktivieren

Achtung: Nach Aktivierung der 802.1X auf dem Port verliert der dort angeschlossene Client seine LAN-Verbindung zum Mikrotik so lange er sich noch nicht authentifiziert hat! Das bitte berücksichtigen.

/interface dot1x server enable [find interface=ether2]

7. Client-Computer einrichten

7.1 Linux

Für einen Test von 802.1x am Client nehme ich hier als Beispiel eine Arch-Linux Distribution. Das Aufbauen der Verbindung gelingt über mehrere Varianten, ich greife hier beispielhaft die gebräuchlich Methoden von wpa_supplicant und NetworkManager auf. Ihr müsst also wählen welche Variante ihr nutzen wollt.

7.1.1 WPA_SUPPLICANT

Falls wpa_supplicant noch nicht installiert sein sollte installieren wir dieses als erstes

sudo pacman -S wpa_supplicant

Dann legen wir unter /etc/wpa_supplicant/wpa_supplicant.conf eine Konfigurationsdatei an und fügen folgenden Inhalt ein:
(eigene Werte und Pfade anpassen):

eapol_version=2
ap_scan=0
network={
	key_mgmt=IEEE8021X
	eap=TLS
	identity="DOT1X_CLIENT1"  
	private_key="/path/to/DOT1X_CLIENT1.p12"  
	private_key_passwd="Passw0rd"  
	eapol_flags=0
}

Die identity muss dem Common-Name im Client-Zertifikat und den Namen des Users im User-Manager entsprechen.

Für den ersten Test starten wir wpa_supplicant unter Angabe des Pfades zur oben erstellten Konfigurationsdatei, dem Parameter -D der den Driver auf "wired" (kabelgebunden) festlegt und dem Interface (-i) welches wir freischalten möchten:

wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -D wired -i eth0

Die Ausgabe sollte dann ähnlich wie diese aussehen

Nach Authentifizierung kann der Befehl mit CTRL+C abgebrochen werden.

Auf dem Mikrotik sollte dann die entsprechende Freigabe für das Interface zu sehen sein und das Interface auf "authorized" stehen:

Die Zähler am Radius-Client des Mikrotiks sollten das ebenfalls bestätigen

Und der User-Manager eine aktive Session anzeigen

Für das dauerhafte Einrichten von wpa_supplicant als systemd Dienst macht ihr dann folgendes:

Als erstes benennt ihr die Konfiguration nach diesem Schema um: wpa_supplicant-<INTERFACENAME>.conf und platziert diese Datei dann im Verzeichnis /etc/wpa_supplicant. Ist der Interface-Name also z.B. eth0 sollte die Konfigurationsdatei als /etc/wpa_supplicant/wpa_supplicant-eth0.conf abgelegt werden.

Dann aktiviert ihr die passende systemd-unit mit diesem Befehl (das eth0 wieder durch euer Interface ersetzen)

sudo systemctl enable wpa_supplicant@eth0 --now

Damit wird der Dienst aktiviert und sofort als auch beim nächsten Boot automatisch gestartet, und schaltet den Port automatisch frei.

7.1.2 Network-Manager

Wenn ihr den Network-Manager benutzen wollt benötigt ihr ebenfalls das CA Zertifikat und den *.p12/*.pfx Zertifikats-Container und legt sie in einem Verzeichnis eurer Wahl ab.

Auf der grafischen Oberfläche des NetworkManager wählen wir nun unsere Ethernet-Verbindung für die wir 802.1x aktiveren wollen aus und öffnen die Einstellungen auf dem Tab 802.1X-Sicherheit, dort tragen wir unsere Daten wie folgt ein.

Wer es lieber mit der Konsole hält der kann auch die CLI des NetworkManager nutzen (Interface,Pfade und Passwort anpassen)

sudo nmcli conn modify eth0 802-1x.eap tls 802-1x.identity DOT1X_CLIENT 802-1x.client-cert /home/user/DOT1X_CLIENT.p12 802-1x.ca-cert /home/user/DOT1X_CA.crt 802-1x.private-key /home/user/DOT1X_CLIENT.p12 802-1x.private-key-password Passw0rd
sudo nmcli conn up eth0

oder die Verbindung direkt unter /etc/NetworkManager/system-connections/*.nmconnection bearbeiten und danach mittels nmcli conn reload aktualisieren.

Nach dem Speichern der Eigenschaften wird der NetworkManager die Verbindung erfolgreich aktiveren sofern alle Daten korrekt sind. Sollte es nicht auf Anhieb klappen, als erstes den Adapter de- und wieder aktivieren und überprüfen ob das Interface eine IP erhält.

7.2 Windows

Für Windows gibt es bei der Nutzung des Mikrotik User-Managers zur Zeit noch eine Einschränkung für die Computer-Authentifizierung die damit leider noch nicht möglich ist da Windows dem Computernamen automatisch immer das Prefix host/ voranstellt. Das ist im Normalfall kein Problem jedoch hat der User-Manager die Eigenheit das in Benutzernamen keine Slashes möglich sind und somit der Name für EAP-TLS nicht korrekt im User-Manager hinterlegt werden kann.
Bei der Benutzerauthentifizierung hingegen gibt es diesbezüglich keine Einschränkung.

Unter Windows 11 geht ihr für die Benutzerauthentifizierung exemplarisch folgendermaßen vor:

7.2.1 CA- und Benutzerzertifikat ins System importieren

Als erstes importiert ihr das CA Zertifikat in die vertrauenswürdigen Stammzertifizierungsstellen des Computers. Und den *.p12/*.pfx Container in den User-Zertifikats-Store.

CA importieren

User-Zertifikat importieren

7.2.2 Aktivieren von 802.1x

Dann öffnet die Systemeinstellungen mittels WIN+I und wählt Netzwerk und Internet

Dort aktiviert ihr die 802.1x Authentifizierung mit EAP-TLS

Nun wechseln wir zurück in die klassische Systemsteuerung und nehmen noch ein paar Detaileinstellungen vor, dazu tippen wir im Windows-Startmenü ncpa.cpl ein und öffnen damit die Netzwerkverbindungen, dort wählen wir unsere Netzwerkverbindung aus und wählen im Kontextmenü Eigenschaften und stellen die Eigenschaften wie folgt ein:

Nach dem Speichern wird Windows den Anmeldedialog präsentieren falls wir das Häkchen für die Nutzung eines alternativen Benutzernamens gewählt haben:

War der Vorgang erfolgreich bestätigt das der Dialog

8. Dynamische VLAN-Zuweisung für den Port

Es lässt sich auch statt einer statischen VLAN-Zuweisung des Ports über die PVID auch eine dynamische VLAN-Zuweisung für den Port über den User-Manager vornehmen.
Wie bei den gängigen Radius-Servern wird dies auch hier über Radius-Attribute geregelt die der Radius-Server an den Authenticator im "Access-Accept" Paket übermittelt und dieser dann den Port in das jeweilige VLAN legt.
Die Attribute die wir für die port basierte Authentifizierung benötigen sind bei Mikrotik und 802.1x im generellen mindestens folgende:

Attribut	Wert	Beschreibung
Tunnel-Type	13	13 steht für "VLAN" siehe https://tools.ietf.org/html/rfc2868#section-3.1)
Tunnel-Medium-Type	6	6 steht für "IEEE-802" siehe https://tools.ietf.org/html/rfc2868#section-3.2
Tunnel-Private-Group-ID	10	Das ist unsere VLAN ID

Damit der Usermanager diese Attribute bei einer "Access-Accept" Antwort mitsendet, müssen wir die Attribute dem User-Manager erst einmal bekannt machen und anlegen (nur falls sie noch nicht existieren):

/user-manager attribute
add name=Tunnel-Type type-id=64 value-type=uint32
add name=Tunnel-Medium-Type type-id=65 value-type=uint32
add name=Tunnel-Private-Group-ID type-id=81 value-type=string

Eine Liste der im Usermanager möglichen Attribute findet sich hier:
https://help.mikrotik.com/docs/display/ROS/User+Manager#UserManager-Attr ...

Jetzt kann man die Attribute beim Anlegen oder Ändern eines Users oder einer Benutzergruppe mit individuellen Werten belegen.
Hier exemplarisch für einen User den man dynamisch dem VLAN 10 zuordnet:

Auf der Konsole lässt sich das so nutzen

/user-manager user add name=DOT1X_CLIENT1 attributes=Tunnel-Private-Group-ID:10,Tunnel-Type:13,Tunnel-Medium-Type:6 

Wenn sich der User nun wie oben gezeigt am Port authentifiziert, wird der mit 802.1x geschützte Port in der Bridge des Mikrotik für dieses VLAN automatisch als untagged in dem VLAN hinzugefügt und wird damit Mitglied des angegebenen VLANs. Geht der Port wieder in den Status "un-authorized" wird der Port auch automatisch wieder als untagged Port aus dem VLAN entfernt.
Damit die dynamische Zuweisung auch funktioniert muss der Port natürlich vorher der Bridge schon einmal als Port zugewiesen werden da ansonsten die dynamische Port-Zuweisung fehl schlägt.

Hier sieht man im LOG des Mikrotik wie der User-Manager unsere hinzugefügten Attribute an den Mikrotik verschickt:

Ebenfalls wird nun das zugewiesene VLAN für den Port aufgeführt:

9. Troubleshooting am Mikrotik

Sollte es wieder erwarten zu Problemen kommen, sollte man als erstes das LOG um die radius und manager Topcs ergänzen, dann erhält man im LOG detaillierte Informationen über die versendeten Radius-Pakete und die User-Manager Meldungen.

Wünsche euch nun viel Erfolg bei der Umsetzung

@colinardo

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 577655

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

Ausgedruckt am: 03.12.2024 um 17:12 Uhr

21 Kommentare

Neuester Kommentar

Das sind ja mal gute News von Mikrotik.

Interessant und auch löblich das MT sich nun auch an die Standard Radius Attribute für VLANs hält und die Vendor spezifischen Attribute wohl nicht mehr zwingend sind.
Dein Einverständnis vorausgesetzt hab ich es mit dem o.a. Tutorial verlinkt.
Offizielle MT Doku hier.

Zitat von @aqui:
Dein Einverständnis vorausgesetzt hab ich es mit dem o.a. Tutorial verlinkt.

Selbstredend

.Danke dir!

Hallo @colinardo,

Danke für das vorzügliche Tutorial! Ich finde die Geräte und Router OS klasse.
Zu 802.1x bei MT aber zwei Fragen:

1. Sehe ich das richtig, dass es sich bei der Mikrotik-Umsetzung faktisch um den alten 802.1x (2004) Standard handelt, der mittels zwischen einen authorisierten Client und MT-Port geschalteten Simpel-Switch umgangen werden kann?
Wenn ich das richtig verstanden habe, hat erst die Anpassung von 802.1x (2010) dies (u.a.) berücksichtigt, indem MACSec (802.1AE) eingeführt wurde. Darüber hinaus gibt es (kenne da nur Cisco) herstellerspezifische Umsetzungen. Cisco unterstützt z.B. MACSec nur oberhalb der SG/CBS-Serie, hat für die KMU-Switche aber immerhin eine Lösung namens "Multi-Sessions" geschaffen, mit der sich, wenn ich das richtig verstehe, jeder am Port angeschlossene Client individuell authentifizieren muss.

2. Wenn das bei Router OS fehlt, ist dort dann die (aufwändige) Radius-Implementierung von 802.1x im LAN mit Blick auf die Sicherheit des Netzes überhaupt noch sinnvoll?
Ich hätte dann zwar immerhin dynamische VLAN-Zuweisung aber keine echte Sicherheit und könnte einen MT-Switch dann doch wohl nur in bereits sicheren Umgebungen einsetzen.

Danke und viele Grüße, commodity

Edit: Da ist offenbar was in der Pipeline: https://forum.mikrotik.com/viewtopic.php?t=164427

Servus @commodity,

1. Sehe ich das richtig, dass es sich bei der Mikrotik-Umsetzung faktisch um den alten 802.1x (2004) Standard handelt, der mittels zwischen einen authorisierten Client und MT-Port geschalteten Simpel-Switch umgangen werden kann?

Ja, zumindest in der alten Beta ist das so, sobald der Port freigeschaltet wurde geht da so ziemlich alles, natürlich nur wenn sich auch der Client authentifiziert nachdem man das Kabel gezogen hat.

Zitat:
https://help.mikrotik.com/docs/display/ROS/Dot1X

A RouterOS dot1x server acts as an authenticator. An interface where dot1x server is enabled will block all traffic except for EAPOL packets which is used for the authentication. After client is successfully authenticated, the interface will accept all received traffic on the port. If the interface is connected to a shared medium with multiple hosts, the traffic will be accepted from all hosts when at least one client is successfully authenticated. In case of failed authentication, it is possible to accept the traffic with a dedicated port VLAN ID.

In neueren Beta ist MACSec schon eingezogen wohl aber noch nicht ganz komplett bzw. lückenhaft, konnte es aber bisher noch nicht testen.

2. Wenn das bei Router OS fehlt, ist dort dann die (aufwändige) Radius-Implementierung von 802.1x im LAN mit Blick auf die Sicherheit des Netzes überhaupt noch sinnvoll?

Es hindert halt Otto-Normalo daran sich halt mal schnell an Ports ins Netz zu schalten die bspw. an IP-Cams oder dergleichen hängen.
Auch wenn aktuell kein aktiver Client am Port hängt verhindert es das der Port missbraucht wird, halt nur so lange bis ein Client sich wieder dort einloggt.
Aber man hat ja alternativ noch die Möglichkeit eine weitere Sicherheitsebene einzuziehen (IPSec & Firewall & Co.)
Ist halt nur eine weitere Ebene die hier eben nicht der Weisheits letzter Schluss in Sachen Sicherheit ist.

Grüße Uwe

Zumindestens bei anderen aktuellen Switches ist das schon lange nicht mehr so das man es per Switch davor aushebeln kann, denn das Forwarding ist immer Mac abhängig und wird nur auf Basis der Mac gemacht. Auch wenn einer den Port öffnet können andere Macs am gleichen Port NICHT durch.
Stichwort Multi- oder single Host Port Authentication. Beherrschen mittlerweile alle besseren Switches.
Wurde früher auch mal als Mac based VLANs bezeichnet und ist heute, wie bereits gesagt, eigentlich mittlerweile überall Standard... Wenn MT noch nicht so weit ist, ist das natürlich schade.

Zitat von @aqui:

Zumindestens bei anderen aktuellen Switches ist das schon lange nicht mehr so das man es per Switch davor aushebeln kann, denn das Forwarding ist immer Mac abhängig und wird nur auf Basis der Mac gemacht. Auch wenn einer den Port öffnet können andere Macs am gleichen Port NICHT durch. Wurde früher auch mal als Mac based VLANs bezeichnet und ist heute eigentlich mittlerweile überall Standard... Wenn MT noch nicht so weit ist, ist das natürlich schade.

Naja, ein MAC-Filter ist in der Firewall des Mikrotik schnell hinzugefügt aber wie wir ja alle wissen , MAC Adressen lassen sich ja bekanntlich faken ...

p.s. Habe das MACSec Interface der aktuellen Beta mal getestet, scheint wohl noch nicht komplett zu sein, die Interfaces schicken zwar gegenseitig EAPOL Frames raus, nehmen sie aber offensichtlich noch nicht an und die Interfaces bleiben im Status "negotiating" trotz korrekt konfiguriertem CAK und CKN.

Danke Euch für die Anmerkungen. Ja, ich war auch etwas irritiert, als ich die Doku gelesen habe. Bei Mikrotik (oder generell) darf man 802.1x eben nicht als Sicherheitsfeature sehen.
Das schöne an den MTs ist aber, dass sie sich entwickeln, wo bei anderen gar nichts passiert. Und es gibt ja andere Lösungswege - oder halt Cisco

Viele Grüße, commodity

Hast du die MacSec Funktion mal mit der nun Stable 7.1.1 verifiziert ? Gibts da irgendwelche Änderungen im Status ?

Zitat von @aqui:

Hast du die MacSec Funktion mal mit der nun Stable 7.1.1 verifiziert ? Gibts da irgendwelche Änderungen im Status ?

Steht noch aus, glaube aber im Mikrotik Forum schon gelesen zu haben das es noch immer nicht fertig ist.

Zitat von @colinardo:
Steht noch aus, glaube aber im Mikrotik Forum schon gelesen zu haben das es noch immer nicht fertig ist.

Gerade gecheckt. Status quo hat sich mit Version 7.1.1 bei MACsec nicht geändert bei der 7.2rc1 ebenso wenig (status steht weiterhin nur bei negotiating, weiter kommt es nicht), die aktuelle Prio liegt da wohl momentan erst mal die Version 7 in den Basis-Features wirklich stable zu bekommen.

Beide pusten EAPOL Frames in den Äther, aber das interessiert die Gegenseite jeweils nicht.

Danke für das Feedback. Bleibt also weiter spannend an der Baustelle...
Bleibt ja dann nur noch das (Beta) mit dem nun offiziellen Launch der 7er Firmware aus der Überschrift zu nehmen. 😉

Zitat von @aqui:

Danke für das Feedback. Bleibt also weiter spannend an der Baustelle...
Bleibt ja dann nur noch das (Beta) mit dem nun offiziellen Launch der 7er Firmware aus der Überschrift zu nehmen. 😉

Ja wenn da nur nicht ein Bug in der aktuellen "Stable" 7.1.1 wäre der das dynamische Hinzufügen des Ports zu einem VLAN verhindert. Ohne dynamische VLAN Zuweisung klappt es, aber mit nich, da kommt es zu einem nicht weiter definierten Fehler im Log
#edit# Mein Fehler, meine Migrations-Config war verbuggt.

Uhhh, das ist böse. OK, dann heisst es auch hier wohl warten auf die nächsten Patch Releases...

Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.

Zitat von @aqui:

Uhhh, das ist böse. OK, dann heisst es auch hier wohl warten auf die nächsten Patch Releases...

Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.

Ohhhh my fault, da muss ich doch zurückrudern, war ein Migrationsfehler der Test-VM! Sorry, klappt wieder

👍
Mit externem Radius auch fehlerfrei. Obwohl ja jetzt im Mikrotik Umfeld mit dem onboard Radius in 7.3 obsolet.

Zur Info an alle die hier an MACsec interesse gezeigt haben:

In der aktuellen RouterOS Version 7.6Beta8 (Testing channel), funktioniert nun endlich auch MACsec grundlegend!

Hier der Test zwischen zwei Mikrotiks mit der aktuellen Testing-FW:

Der Test von einem ArchLinux und wpa_supplicant zu einem Mikrotik verlief ebenso positiv:

Bitte beachten das diese spezielle Firmware für Geräte die auf der TILE Architektur basieren und auch die RB5009 Serie laut Mikrotik nicht zu empfehlen ist wenn MACsec zum Einsatz kommt.

Important note!!!
Version not recommended on TILE and RB5009 devices if MACsec is used;

https://mikrotik.com/download/changelogs/testing-release-tree#show-tab-t ...

Grüße Uwe

hab das gerade mit 7.14.3 durch-exerziert, klappt ganz hervorragend!

Offenbar hat sich aber die Syntax am CLI bissl geändert. Zwei Dinge sind mir aufgefallen:

/interface dot1x server add interface=ether2 enabled=no

aus enabled wurde jetzt disabled. Es heißt jetzt also:

/interface dot1x server add interface=ether2 disabled=yes

/user-manager profile add name=dot1x name-for-users=dot1x

hier scheint der Parameter validity neuerdings mandatory zu sein. Gibt man ihn nicht an, erscheint ein entsprechender Prompt. Da hab ich einfach <return> gedrückt, was dazu führt, dass validity=unlimited gesetzt wird.

@rapkin 👍 Merci für das Update, habe es oben korrigiert, und noch ein paar Ergänzungen etc. hinzugefügt.

Gruß @colinardo

Für die CLI affine Linux Fraktion hier nochmal ein Network Manager Connection Profil ohne GUI:
(Beispiel Raspberry Pi Zero2W mit USB Ethernet Adapter)

[connection]
id=USB-Adapter
uuid=538c2100-2175-319a-a857-a3bcce31890f
type=ethernet
interface-name=eth1

[ethernet]

[802-1x]
eap=tls;
identity=DOT1X_CLIENT
ca-cert=/home/user/.certs/DOT1X_CA.crt
client-cert=/home/user/.certs/DOT1X_CLIENT.p12
private-key=/home/user/.certs/DOT1X_CLIENT.p12
private-key-password=Passw0rd

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy] 

Wie man die Zertifikate mit OpenSSL z.B. auf dem RasPi selber generiert ist HIER genau beschrieben!

Die grafische WinBox GUI Variante für die einfache Erstellung des Client Zertifikats geht so:
(Der Common Name (CN) entspricht dabei der "Identity")

Oder auf der Konsole mit der cli des NetworkManager.

sudo nmcli conn modify eth0 802-1x.eap tls 802-1x.identity DOT1X_CLIENT 802-1x.client-cert /home/user/DOT1X_CLIENT.p12 802-1x.ca-cert /home/user/DOT1X_CA.crt 802-1x.private-key /home/user/DOT1X_CLIENT.p12 802-1x.private-key-password Passw0rd
nmcli conn up eth0