9
PacketFence MAC-Authentifizierung
Hallo,
bin neu in einem Unternehmen und möchte sehr gerne ein NAC-System implementieren, erstmalig nur für MAC-Authentifizierung und dynamische VLAN-Zuweisung.
Gesagt - getan.
Geworden ist es bei mir PacketFence auf Basis einer Debian 12 Maschine. Netzwerk besteht aus einigen Aruba 2930F und Aruba 2540.
Die VLAN's haben ich gemäß Anleitung als Roles im PacketFence definiert, Switches wurden auch angelegt.
Am ersten Switch habe ich Testweise folgende Config eingespielt:
Der Test ergab folgende Erkenntnis:
Genau das selbe Spiel wenn ich die Role eines Devices ändere, es wird erst bei ab- und anstecken ein neuer Discover geschickt.
Habe herausgefunden, dass es auch die Option am Switch aaa port-access mac-based 38 reauth-period gibt.
Diese Option gibt an, nach welcher Zeit das Device sich wieder beim Radius-Server melden muss.
Nun meine Frage, gibt es eine Möglichkeit es so einzustellen, das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
Klar ich könnte einfach die Reauth-period auf einen sehr kleinen Wert stellen, könnte mir jedoch vorstellen das Packetfence oder die Switches selber dies nichtmehr handlen könnten (Stichwort "Paketbombardierung").
Wäre toll wenn sich hier im Forum der ein oder andere befinden würde der mir weiterhelfen kann!
Gruß
bin neu in einem Unternehmen und möchte sehr gerne ein NAC-System implementieren, erstmalig nur für MAC-Authentifizierung und dynamische VLAN-Zuweisung.
Gesagt - getan.
Geworden ist es bei mir PacketFence auf Basis einer Debian 12 Maschine. Netzwerk besteht aus einigen Aruba 2930F und Aruba 2540.
Die VLAN's haben ich gemäß Anleitung als Roles im PacketFence definiert, Switches wurden auch angelegt.
Am ersten Switch habe ich Testweise folgende Config eingespielt:
radius-server host X.X.X.X key "key"
radius-server host X.X.X.X dyn-authorization
radius-server host X.X.X.X time-window 0
aaa server-group radius "PacketFence" host X.X.X.X
aaa accounting network start-stop radius server-group "PacketFence"
aaa authentication mac-based chap-radius server-group "PacketFence"
aaa port-access mac-based 37-38
aaa port-access mac-based 37 addr-moves
aaa port-access mac-based 38 addr-movesDer Test ergab folgende Erkenntnis:
- Stecke ein Gerät an --> Status unregistriert --> Kriege eine APIPA zugewiesen
- Ändere Status im PacketFence auf registriert und vergebe eine Role --> tut sich nichts
Genau das selbe Spiel wenn ich die Role eines Devices ändere, es wird erst bei ab- und anstecken ein neuer Discover geschickt.
Habe herausgefunden, dass es auch die Option am Switch aaa port-access mac-based 38 reauth-period gibt.
Diese Option gibt an, nach welcher Zeit das Device sich wieder beim Radius-Server melden muss.
Nun meine Frage, gibt es eine Möglichkeit es so einzustellen, das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
Klar ich könnte einfach die Reauth-period auf einen sehr kleinen Wert stellen, könnte mir jedoch vorstellen das Packetfence oder die Switches selber dies nichtmehr handlen könnten (Stichwort "Paketbombardierung").
Wäre toll wenn sich hier im Forum der ein oder andere befinden würde der mir weiterhelfen kann!
Gruß
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-ID: 669798
Url: https://administrator.de/contentid/669798
Printed on: December 7, 2024 at 19:12 o'clock
9 Comments
Latest comment
das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
Das klappt so bei MAB leider nicht. Zumindestens nicht mit den üblichen Bordmitteln. Das Retriggern der Authentisierung passiert nur dann wenn...- A Reauthentication überhaupt aktiviert ist und nach Ablauf des Reauth Timers und wenn die Port Mac noch in der Mac Forwarding Tabelle des Switches ist.
- B wenn die Mac Adresse aus der L2 Forwarding Tabelle ausgetimed sein sollte und der Switch sie am Port durch Traffic neu lernt. (Mac Timeout Parameter)
- C ein Link Loss am Port auftritt durch Trennung oder Standby. Löscht auch sofort den Mac Eintrag.
Das Radius Attribut 28 (Idle Timeout) greift m.E. nicht bei Ethernet NAS. Die Mac Timeout Zeit runterzudrehen hat auch wenig Sinn, denn ein Reauth greift nur dann wenn in der Zeitspanne das Endgerät "stumm" ist, also kein Traffic das Mac Learning retriggert. Bei so geschwätzigen Endgeräten wie Winblows wohl eher Utopie.
Du musst also einen guten Kompromiss deines Reauth Intervalles finden.
Weitere Details zu der Thematik auch HIER und in den weiterführenden Links.
Zitat von @aqui:
Das Radius Attribut 28 (Idle Timeout) greift m.E. nicht bei Ethernet NAS. Die Mac Timeout Zeit runterzudrehen hat auch wenig Sinn, denn ein Reauth greift nur dann wenn in der Zeitspanne das Endgerät "stumm" ist, also kein Traffic das Mac Learning retriggert. Bei so geschwätzigen Endgeräten wie Winblows wohl eher Utopie.
Du musst also einen guten Kompromiss deines Reauth Intervalles finden.
Weitere Details zu der Thematik auch HIER und in den weiterführenden Links.
das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
Nein das klappt so bei MAB leider nicht. Das Retriggern der Authentisierung passiert nur dann wenn...- A Reauthentication überhaupt aktiviert ist und nach Ablauf des Reauth Timers und wenn die Port Mac noch in der Mac Forwarding Tabelle des Switches ist.
- B wenn die Mac Adresse aus der L2 Forwarding Tabelle ausgetimed sein sollte und der Switch sie am Port durch Traffic neu lernt. (Mac Timeout Parameter)
- C ein Link Loss am Port auftritt durch Trennung oder Standby. Löscht auch sofort den Mac Eintrag.
Das Radius Attribut 28 (Idle Timeout) greift m.E. nicht bei Ethernet NAS. Die Mac Timeout Zeit runterzudrehen hat auch wenig Sinn, denn ein Reauth greift nur dann wenn in der Zeitspanne das Endgerät "stumm" ist, also kein Traffic das Mac Learning retriggert. Bei so geschwätzigen Endgeräten wie Winblows wohl eher Utopie.
Du musst also einen guten Kompromiss deines Reauth Intervalles finden.
Weitere Details zu der Thematik auch HIER und in den weiterführenden Links.
Dem muss ich leider widersprechen. Dies funktioniert in Verbindung mit PacketFence und CoA
Dies nutzen wir bei Cisco Meraki Switches in Verbindung mit Packetfence
www.packetfence.org/doc/PacketFence_Installation_Guide.html
documentation.meraki.com/MS/Access_Control/Change_of_Authorization_with_RADIUS_(CoA)_on_MS_Switches
Der Test ergab folgende Erkenntnis:
Dann hast du in PF kein NEtzwerk für unregistriere Geräte mit einer "Splash Page" definiert- Stecke ein Gerät an --> Status unregistriert --> Kriege eine APIPA zugewiesen
Habe herausgefunden, dass es auch die Option am Switch aaa port-access mac-based 38 reauth-period gibt.
Diese Option gibt an, nach welcher Zeit das Device sich wieder beim Radius-Server melden muss.
Nun meine Frage, gibt es eine Möglichkeit es so einzustellen, das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
ja, CoADiese Option gibt an, nach welcher Zeit das Device sich wieder beim Radius-Server melden muss.
Nun meine Frage, gibt es eine Möglichkeit es so einzustellen, das Role-Changes direkt durchgeführt werden und nicht erst nach ab- und anstecken oder ablaufen einer Zeitspanne?
Du hast natürlich Recht! CoA ist die Alternative der Wahl bei der o.a. Anforderung, erfordert aber entsprechenden Support auf den Endgeräten (Switches) des TOs was aus seinem Posting leider nicht hervorgeht.
Gerade eben mal mit dem Freeradius getestet und zumindestens bei Mikrotik, Ruckus ICX und Cisco Catalysten klappt es problemlos wie bei deinen Merakis auch.
Beim Cisco Catalysten sehen die entsprechenden CoA Konfig Zeilen so aus:
(10.2.100.222=Radius Server IP)
Beim Mikrotik Radius Server (User-Manager) dann entsprechend:
Mit debug aaa coa kann man sich das Verhalten dann auch sehr schön auf dem Cisco Switch ansehen. Beim Mikrotik im Log.
Bei Packet Fence werkelt ja ganz sicher auch ein Freeradius im Hintergrund?!
Hier ein Live Beispiel für einen Cisco Catalyst Swich:
Der Cisco führt eine CoA Reauthentication ohne Link Loss für den Client mit dem CoA Vendor spezifischen Attribut 26 Cisco:Avpair=“subscriber:command=reauthenticate” durch.
Das radclient Kommando kann leider keine Werte senden die ein "=" Gleichheitszeichen enthalten wie das o.a. Attribut so das man dieses VSA Attribut als Hex Wert senden muss was aber kein Problem ist. Bei Attributen ohne "=" ist das nicht erforderlich.
Entweder konvertiert man es über einen ASCCI/Hex Konverter oder zieht es direkt aus einem Wireshark Trace.
Daraus erhält man dann den erforderlichen Hex String: (1a29)000000090123737562736372696265723a636f6d6d616e643d726561757468656e746963617465 dessen erste 2 Bytes entfernt werden müssen, da radclient dies übernimmt.
Das resultiert dann für den MAB Client mit der Mac Adresse B827EBF5C6A4 in dem folgenden radclient Kommando:
Ein Wireshark zeigt oben die 2 an den Switch gesendeten CoA Pakete.
Der Switch (IP: 10.1.10.7) quittiert das erwartungsgemäß mit einem ACK und der betreffende Switchport führt dann sofort eine Reauthentication aus ohne den angeschlossenen Client zu disconnecten.
Works as designed! 😉
Dank an @tech-flare für den Wink in die richtige Richtung.
Gerade eben mal mit dem Freeradius getestet und zumindestens bei Mikrotik, Ruckus ICX und Cisco Catalysten klappt es problemlos wie bei deinen Merakis auch.
Beim Cisco Catalysten sehen die entsprechenden CoA Konfig Zeilen so aus:
aaa server radius dynamic-author
client 10.1.10.222 server-key testing123!
port 3799 Beim Mikrotik Radius Server (User-Manager) dann entsprechend:
Bei Packet Fence werkelt ja ganz sicher auch ein Freeradius im Hintergrund?!
Hier ein Live Beispiel für einen Cisco Catalyst Swich:
Der Cisco führt eine CoA Reauthentication ohne Link Loss für den Client mit dem CoA Vendor spezifischen Attribut 26 Cisco:Avpair=“subscriber:command=reauthenticate” durch.
Das radclient Kommando kann leider keine Werte senden die ein "=" Gleichheitszeichen enthalten wie das o.a. Attribut so das man dieses VSA Attribut als Hex Wert senden muss was aber kein Problem ist. Bei Attributen ohne "=" ist das nicht erforderlich.
Entweder konvertiert man es über einen ASCCI/Hex Konverter oder zieht es direkt aus einem Wireshark Trace.
Das resultiert dann für den MAB Client mit der Mac Adresse B827EBF5C6A4 in dem folgenden radclient Kommando:
root@radius:~# echo Calling-Station-Id=B8-27-EB-F5-C6-A4,Attr-26=0x000000090123737562736372696265723a636f6d6d616e643d726561757468656e746963617465|radclient -x 10.1.10.7 coa testing123!
Sent CoA-Request Id 247 from 0.0.0.0:50961 to 10.1.10.7:3799 length 80
Calling-Station-Id = "B8-27-EB-F5-C6-A4"
Cisco-AVPair = "subscriber:command=reauthenticate"
Received CoA-ACK Id 247 from 10.1.10.7:3799 to 10.1.10.222:50961 length 20Der Switch (IP: 10.1.10.7) quittiert das erwartungsgemäß mit einem ACK und der betreffende Switchport führt dann sofort eine Reauthentication aus ohne den angeschlossenen Client zu disconnecten.
CiscoSwitch#debug aaa coa
AAA CoA packet processing debugging is on
Dec 1 11:59:07: COA: 10.1.10.222 request queued
Dec 1 11:59:07: RADIUS: Calling-Station-Id [31] 19 "B8-27-EB-F5-C6-A4"
Dec 1 11:59:07: RADIUS: Vendor, Cisco [26] 41
Dec 1 11:59:07: RADIUS: Cisco AVpair [1] 35 "subscriber:command=reauthenticate"
Dec 1 11:59:07: ++++++ CoA Attribute List ++++++
Dec 1 11:59:07: 0387B8E0 0 00000081 formatted-clid(37) 17 B8-27-EB-F5-C6-A4
Dec 1 2024 11:59:07 CET: %MAB-5-SUCCESS: Authentication successful for client (b827.ebf5.c6a4) on Interface Fa0/1 Dank an @tech-flare für den Wink in die richtige Richtung.
1
Keinerlei Feedback vom TO ist natürlich auch ein Feedback! 
Wenn es das denn nun war als Lösung bitte deinen Thread dann auch als gelöst markieren!
How can I mark a post as solved?
Wenn es das denn nun war als Lösung bitte deinen Thread dann auch als gelöst markieren!
How can I mark a post as solved?
Hallo zusammen,
vielen Dank für die zahlreichen Antworten!
Habe mich mithilfe der Antworten noch bissl reingefuchst, aktueller Stand sieht folgend aus:
CoA ist aktiviert.
Soweit bin ich zufrieden.
Einziges kleines Schönheitsproblem:
Bei registrierten Devices muss immer noch das Kabel ab- und angesteckt werden, wenn die Rollen geändert werden
Kleiner ärgerlicher Umstand, aber zu verkraften. Evtl. wird dies bei Gelegenheit auch noch geändert!
vielen Dank für die zahlreichen Antworten!
Habe mich mithilfe der Antworten noch bissl reingefuchst, aktueller Stand sieht folgend aus:
- Authorisierungsstufe (registered/unregistered) kann geändert werden ohne das die Verbindung vom Device zum
CoA ist aktiviert.
Soweit bin ich zufrieden.
Einziges kleines Schönheitsproblem:
Bei registrierten Devices muss immer noch das Kabel ab- und angesteckt werden, wenn die Rollen geändert werden
Kleiner ärgerlicher Umstand, aber zu verkraften. Evtl. wird dies bei Gelegenheit auch noch geändert!
Bei registrierten Devices muss immer noch das Kabel...
Das widerspricht ja dann komplett dem CoA Gedanken und wäre netztechnisch völlig unsinnig. Außerdem lassen sich so oder so ja immer nur registrierte Endgeräte per CoA reauthentisieren. Zu mindestens wenn mit "registriert" die Mac Adresse bei MAB oder der Dot1x User am Switch gemeint ist.Ansonsten würde der Switch ja auch gar nicht wissen welches Device er reauthentisieren soll. Das klingt eher nach einem Firmware Bug in den Switches.
Bei dem o.a. Catalyst Test und auch Ruckus ICX ist sowas (CoA) erwartungsgemäß nicht erforderlich. Auch die Billigschiene mit Mikrotik verhält sich hier Standard konform und unauffällig.
Freut mich, dass ich dir auch mal auf die Sprünge helfen konnte. Wobei Mit den Hex-Werten ist mir neu, da dies im Meraki mit Packetfence OOTB KlickBunti funktioniert.
Gruß
Zitat von @davzftl:
Hallo zusammen,
vielen Dank für die zahlreichen Antworten!
Habe mich mithilfe der Antworten noch bissl reingefuchst, aktueller Stand sieht folgend aus:
CoA ist aktiviert.
Soweit bin ich zufrieden.
Einziges kleines Schönheitsproblem:
Bei registrierten Devices muss immer noch das Kabel ab- und angesteckt werden, wenn die Rollen geändert werden
Kleiner ärgerlicher Umstand, aber zu verkraften. Evtl. wird dies bei Gelegenheit auch noch geändert!
Dafür gibt es aber meines Wissens nach im Packetfence die Funktion Reevaluate AccessHallo zusammen,
vielen Dank für die zahlreichen Antworten!
Habe mich mithilfe der Antworten noch bissl reingefuchst, aktueller Stand sieht folgend aus:
- Authorisierungsstufe (registered/unregistered) kann geändert werden ohne das die Verbindung vom Device zum
CoA ist aktiviert.
Soweit bin ich zufrieden.
Einziges kleines Schönheitsproblem:
Bei registrierten Devices muss immer noch das Kabel ab- und angesteckt werden, wenn die Rollen geändert werden
Kleiner ärgerlicher Umstand, aber zu verkraften. Evtl. wird dies bei Gelegenheit auch noch geändert!
