IEEE 802.1X mit Captive Portal
Hallo zusammen,
ich möchte den Zugang zu den LAN-Ports via IEEE 802.1X + RADIUS beschränken. Alles was der Layer 3 Swich mit nicht autorisierten Klienten machen kann ist 1) blocken 2) in ein eigenes VLAN hängen.
Gibt es für den Windows-Klienten hier eine einfache Lösung mittels Benutzer / PW zu authentifizieren? Zum Beispiel über Captive Portal? Der Switch würde doch immernoch auf das okay des RADIUS servers warten oder nicht? Alles was ich lese sind irgendwelche Einstellungsorgien... o.O
Seid nett zu mir, ich mache das alles zum ersten mal.
Vielen Dank
ich möchte den Zugang zu den LAN-Ports via IEEE 802.1X + RADIUS beschränken. Alles was der Layer 3 Swich mit nicht autorisierten Klienten machen kann ist 1) blocken 2) in ein eigenes VLAN hängen.
Gibt es für den Windows-Klienten hier eine einfache Lösung mittels Benutzer / PW zu authentifizieren? Zum Beispiel über Captive Portal? Der Switch würde doch immernoch auf das okay des RADIUS servers warten oder nicht? Alles was ich lese sind irgendwelche Einstellungsorgien... o.O
Seid nett zu mir, ich mache das alles zum ersten mal.
Vielen Dank
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672904
Url: https://administrator.de/forum/ieee-802-1x-mit-captive-portal-672904.html
Ausgedruckt am: 16.06.2025 um 04:06 Uhr
25 Kommentare
Neuester Kommentar
Vielleicht noch ein kleiner, ergänzender Tip zum obigen Tutorial und deiner Anforderung:
Das Fallback von nicht im Radius authentisierten Clients in ein bestimmtes Fallback VLAN (das mit dem Captive Portal) kann man auf unterschiedliche Weise handhaben und ist somit maßgeblich von deiner Switch Hardware bzw. dessen Featureset abhängig.
Die meisten Switches haben von sich aus oft schon eine konfigurierbare Fallback Option im Falle von nicht authorisierten Clients.
Sollten sie das nicht haben auf deiner Hardware regelst du das ganz einfach über das Default Profil des Radius wie z.B. Freeradius im o.a. Tutorial.
Und keine Angst, das ist alles kein Hexenwerk und in der Regel ein Nobrainer. Wenn du das Tutorial durcharbeitest hast du alle Werkzeuge dafür an der Hand. 😉
Das Fallback von nicht im Radius authentisierten Clients in ein bestimmtes Fallback VLAN (das mit dem Captive Portal) kann man auf unterschiedliche Weise handhaben und ist somit maßgeblich von deiner Switch Hardware bzw. dessen Featureset abhängig.
Die meisten Switches haben von sich aus oft schon eine konfigurierbare Fallback Option im Falle von nicht authorisierten Clients.
Sollten sie das nicht haben auf deiner Hardware regelst du das ganz einfach über das Default Profil des Radius wie z.B. Freeradius im o.a. Tutorial.
Und keine Angst, das ist alles kein Hexenwerk und in der Regel ein Nobrainer. Wenn du das Tutorial durcharbeitest hast du alle Werkzeuge dafür an der Hand. 😉
MD5 kann der Freeradius natürlich auch! Das sollte also problemlos klappen mit deiner HP Gurke.
Hier funktioniert das sogar mit Win 10 auf einem HP Procurve 2520 Methusalem.
Mit "EAP" ist gemeint das der das klassische EAPoL zum Client macht was ja Standard bei 802.1x ist. Da musst du dir also keinerlei Sorgen machen. Das wird mit dem 2848 ganz sicher klappen!
Im Zweifel immer den Radius mit freeradius -X im Debugger Mode laufen lassen und dir genau ansehen was da abgeht.
Mit "EAP" ist gemeint das der das klassische EAPoL zum Client macht was ja Standard bei 802.1x ist. Da musst du dir also keinerlei Sorgen machen. Das wird mit dem 2848 ganz sicher klappen!
Im Zweifel immer den Radius mit freeradius -X im Debugger Mode laufen lassen und dir genau ansehen was da abgeht.
Wenn es das denn nun war und das eine gangbare Lösung für dich ist, bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Die Radius Implementation in der pfSense ist nicht so homogen integriert wie bei der OPNsense. Beiden gemein ist aber die Verwendung einer lokalen Datenbank. Das Auslagern auf externe Datenbanken sehen diese Implementationen gar nicht vor. Folglich kann es niemals eine "Hineinsynchronisierung" von Benutzer Accounts geben. Das ist netztechnisch unmöglich.
Es gibt lediglich die Möglichkeit entweder das über die Package Verwaltung installierte eigene Freeradius Umfeld zu nutzen und dann mit dem was das bietet oder eben einen vollständig autarken externen Radius Server jedweder Couleur.
Die zentrale Frage die du leider nicht beantwortet hast ist WAS genau die mit deiner Frickelei bezwecken willst? Da kann man jetzt nur wild Kristallkugeln.
Details zur pfSense Radius Implementation auch HIER.
Es gibt lediglich die Möglichkeit entweder das über die Package Verwaltung installierte eigene Freeradius Umfeld zu nutzen und dann mit dem was das bietet oder eben einen vollständig autarken externen Radius Server jedweder Couleur.
Die zentrale Frage die du leider nicht beantwortet hast ist WAS genau die mit deiner Frickelei bezwecken willst? Da kann man jetzt nur wild Kristallkugeln.
Details zur pfSense Radius Implementation auch HIER.
Ich hätte gerne einen geschützten VLAN Bereich aber auf dem gleichen Switch ...
Mit dynamischer VLAN Zuweisung für die Clients via Radius für dieses VLAN??Das ist ja dann kein Problem wenn du die VLAN ID im Radius den betreffenden Clients mitgibst.
Ansonsten legst du dir, wie generell ja üblich, ein statisches VLAN dafür an und weist dann eben statisch die Ports den Clients zu.
Die VLAN ID anlegen musst du aber so oder so.
Leider etwas schwer verständlich was du unter "Geschützt" genau verstehst bzw. was dein Ziel ist wenn du nur in so kurzen Sätzen antwortest?! 🤔
OK, verstanden. Das ist natürlich problemlos möglich und wurde dir oben auch schon genannt sofern man denn helfende Antworten auch liest?! 🧐
Dafür gibt es üblicherweise 2 Optionen dies umzusetzen:
1.)
Die erste Option ist die klassische und weniger abhängig vom .1x oder MAB Featureset des Switches oder WLAN APs.
Hier Definierst du im Radius Server die Default Aktion. Das also was der Radius machen soll wenn es keine positive Authentisierung des Clients gibt. Im Default ist das immer ein Access denied auf dem Radius, so das der betreffende Client rausgeschmissen wird.
Als Alternative kann man dem Radius über das Default Profil auch sagen das er nicht authorisierte Clients im Default erlauben soll und ihnen dann aber ein entsprechendes VLAN mitgibt. Diese User werden somit in ein isoliertes "Gummizellen" oder Gast VLAN auf dem Switch gezwungen.
Wie man diese Lösung mit dem Freeradius schnell und unkompliziert löst erklärt dir dieser Forenthread.
2.)
Die andere Option ist von deiner Switchhardware bzw. dem Featureset dessen MAB und 802.1x Funktion abhängig.
Viele dieser Switches supporten ein sog. Authentication Fail VLAN. Man kann dann über die Switchkonfig eine VLAN ID mitgeben für den Fall das der Client vom Radius ein Access denied bekommt.
Als Beispiel einmal die Port Konfig eines Cisco Switches die sowas veranschaulicht:
Anderes Beispiel einer Ruckus ICX Switch Konfiguration:
Hier siehst du das der Switch selber bei gescheiterter Radius Authorisierung den Port selber automatisch ins VLAN 20 bzw. 99 legt.
Bei WebGUI Switches ist das identisch da gibts dann einen Haken für die KlickiBunti Fraktion.
Mit beiden Optionen lässt sich das also recht einfach umsetzen.
Die Kommunikation der "Gummizellen" VLAN Teilnehmer untereinander unterbindet man auf dem Switch immer mit der Private VLAN oder isolated VLAN Funktion. (Portisolation)
P.S.:
Dafür gibt es üblicherweise 2 Optionen dies umzusetzen:
1.)
Die erste Option ist die klassische und weniger abhängig vom .1x oder MAB Featureset des Switches oder WLAN APs.
Hier Definierst du im Radius Server die Default Aktion. Das also was der Radius machen soll wenn es keine positive Authentisierung des Clients gibt. Im Default ist das immer ein Access denied auf dem Radius, so das der betreffende Client rausgeschmissen wird.
Als Alternative kann man dem Radius über das Default Profil auch sagen das er nicht authorisierte Clients im Default erlauben soll und ihnen dann aber ein entsprechendes VLAN mitgibt. Diese User werden somit in ein isoliertes "Gummizellen" oder Gast VLAN auf dem Switch gezwungen.
Wie man diese Lösung mit dem Freeradius schnell und unkompliziert löst erklärt dir dieser Forenthread.
2.)
Die andere Option ist von deiner Switchhardware bzw. dem Featureset dessen MAB und 802.1x Funktion abhängig.
Viele dieser Switches supporten ein sog. Authentication Fail VLAN. Man kann dann über die Switchkonfig eine VLAN ID mitgeben für den Fall das der Client vom Radius ein Access denied bekommt.
Als Beispiel einmal die Port Konfig eines Cisco Switches die sowas veranschaulicht:
interface GigabitEthernet0/4
description Authentication MAP plus Dot1x
switchport mode access
authentication event fail action authorize vlan 99 <<---
authentication port-control auto
authentication periodic
mab
dot1x pae authenticator
spanning-tree portfast
authentication
auth-default-vlan 3
restricted-vlan 20 <<--
auth-fail-action restricted-vlan <<--
dot1x enable
dot1x enable ethe 1/1/1 to 1/1/4
Bei WebGUI Switches ist das identisch da gibts dann einen Haken für die KlickiBunti Fraktion.
Mit beiden Optionen lässt sich das also recht einfach umsetzen.
Die Kommunikation der "Gummizellen" VLAN Teilnehmer untereinander unterbindet man auf dem Switch immer mit der Private VLAN oder isolated VLAN Funktion. (Portisolation)
P.S.:
und Hacken in den Diensten setzen
Hacken? 🤔 Die ⛏️ benutzt man doch eigentlich nur im Garten gegen das Unkraut oder hat sie unten am Fuß?! In der IT hacken ja in der Regel nur Hacker. Du meinst vermutlich einen Haken, oder?Wenn ich mit einem Tag komme, weigert sich PfSense mir die IP-Adresse des betreffenden VLANs zu geben.
Zeigt klar das du an der pfSense und/oder am ihr angeschlossenen Switch bzw. dessen Uplink Port zur pfSense etwas falsch konfiguriert hast!Ohne ein paar hilfreiche Konfig Screenshots vom Setup deiner beiden beteiligten Komponenten müssen wir natürlich Kristallkugeln was der genaue Grund sein könnte?! 🤔
Die VLAN Interaktion zwischen pfSense und Switch sollte natürlich als Allererstes sauber funktionieren, denn darauf baut ja schliesslich alles weitere auf.
Halte dich einfach und stressfrei an das hiesige VLAN Tutorial was alle Schritte auf pfSense und Switch im Detail und für Laien leicht verständlich und mit bunten Bildern erklärt! Dann wird mit deinem VLAN Setup auch ganz sicher nichts schief gehen!
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
und ihr könnt mir helfen...
Klar können wir das! 😉Erstmal vorab zu deinem Screenshot. Eine "VLAN 0" (Null) ID gibt es nicht die ist im 802.1q Standard nicht vorgesehen. Vergiss den Unsinn also wieder ganz schnell...
Das Default VLAN 1 ist auf einem Trunk in der Regel das sog. Native VLAN oder auch das PVID VLAN.
Das bezeichnet das VLAN in das an einem Trunk Interface alle UNgetaggten Frames, also solche ohne VLAN Information (Tag) geforwardet werden.
Auf der pfSense oder OPNsense ist es der Traffic der vom physischen Parent Interface der Firewall kommt. Der wird an dem Trunkport immer UNtagged gesendet
Details zu der Thematik auch in der VLAN Schnellschulung.
Das nur als kurze VLAN Auffrischung vorweg.
Dein o.a. erster Screenshot ist recht verwirrend.
In den Zeilen ist die Rede von WiFi, Privat und LAN mit IP Adressen die dann aber in den Spalten völlig unterschiedlich zu den dort genannten VLANs sind. Damit ist die eigentliche IP Adressierung der VLANs leider unklar.
Hilfreich ist die VLAN ID in das 3te Byte bei Verwendung von /24er Netzadresse zu "kodieren". Das hilft später bei der Installation und beim logischen Erkennen der VLAN IP Adressen. Mit 666 als ID wird das natürlich etwas schwierig. Letztlich aber alles nur kosmetisch.
Wir nehmen also einmal folgende Adressierung und VLAN ID an. (Wie gesagt "0" ist Unsinn)
- VLAN 1 = UNtagged = PVID VLAN = 192.168.10.0 /24 - Firewall VLAN 1 IP: 192.168.10.1 (Parent Interface)
- VLAN 200 = Tagged = 192.168.11.0 /24 - Firewall VLAN 200 IP: 192.168.11.1
- VLAN 666 = Tagged = 192.168.12.0 /24 - Firewall VLAN 666 IP: 192.168.12.1
Problem: Leider bekomme ich für den Klienten keine IP
Nebenbei erfährt man man das deine Firewall virtualisiert ist. 🙄Das ist generell kein Problem aber es kommt entscheidend darauf an WIE die virtuellen Interfaces der Firewall an den vSwitch des Hypervisors angebunden ist!!!
Das o.a. Fehlerbild zeigt ganz klar das hier dein Fehler liegt!
In einer virtualisierten Firewall hast du in deinem Falle 3 Netzwerk Interfaces (WiFi, Privat, LAN). Je nachdem WIE der vSwitch des HyperV dies erfordert werden die an den vSwitch angebunden.
Bei so gut wie allen vSwitches passiert das UNtagged und man bestimmt mit der vSwitch Konfiguration in welchem VLAN man diesen Traffic haben will und vor allem WIE der vSwitch diesen VLAN Trunk über eine einzelne NIC nach außen weiterleitet. Das bedeutet das üblicherweise kein Tagging dieser der virtuellen Firewall Netzwerkkarten erfordert.
Zu 98% hast du hier einen Konfigurationsfehler gemacht, denn das Fehlerbild zeigt eindeutig das es keinerlei Layer 2 Verbindung zwischen deinem internen vSwitch im HyperV mit den Netzwerkkarten der Firewall gibt. Auf das Setup solltest du dich mit der Fehlersuche also nochmals konzentrieren.
Als Hilfe kannst du dir im Folgenden einmal ansehen wie so ein Set auf auf VmWare und auf Proxmox auszusehen hat.
pfSense unter Proxmox
pfSense unter ESXi / VmWare
Allgemeine Tips zur Anpassung einer virtualisierten pfSense/OPNsense findet du HIER.
Der Switch an sich bekommt immer eine IP (aus Range Vlan-ID = 0 !)
Wie gesagt die VLAN ID "0" ist falsch aber du redest hier sehr wahrscheinlich vom PVID VLAN (untagged).Das bestätigt zusätzlich den Verdacht deiner falschen Anbindung der 2 anderen Firewall Interfaces bzw. virtuellen NICs an den vSwitch! Hier ist also mehr Info zum HyperV vSwitch Setup erforderlich um dir zielführend helfen zu können.
Hänge ich bei der Switch den Klienten an einen non-.1x Port, bekommt er auch eine IP aus einem non-Vlan Bereich und kann ins Internet.
Das ist auch klar und erwartbar, denn hier schiebst du ja schlicht und einfach nur das ungetaggte PVID VLAN durch.Auch der PC mit dem Radiusserver ist erreichbar und mit pfSense testbar, wenn auch aus einer anderen Client-ID Range.
Auch das klar und erwartbar, denn die Management IP des Switches liegt in der Regel im Default immer im PVID VLAN und mit der IP sendet er die Radius Requests ja auch an den Radius Server. Alles klassischer Standard also.Wenn du allerdings in der Basis Grundkonfiguration ganz ohne Radius schon gar nicht den grundsätzlichen Betrieb der 2 zusätzlichen VLANs zum Laufen bekommst wird natürlich der ganze Rest scheitern.
Eine saubere VLAN Funktion deiner 3 Netze muss natürlich am physischen Switch gegeben sein erstmal auch ohne Radius. Darauf baut ja der Rest der Funktionen auf. Einfache Logik!
Dein erster Schritt ist also den vSwitch im HyperV und die korrekte VLAN Funktion zum Fliegen zu bringen. Ohne das das klappt macht es keinen Sinn den 2ten vor dem ersten Schritt zu machen bzw. deine ansonsten richtigen Schritte 1 bis 7 umzusetzen.
Ergebniss sieht so aus: Status Closed bedeutet, dass "Either no client is connected or the connected client has not received authorization through 802.1X authentication"
Ja, auch das ist ebenso wieder klar und erwartbar, denn alle Ports die für die 802.1x Port Security aktiviert sind sind im Default (Mode "Auto") blockiert. Soll ja auch so sein wenn sich kein Client authorisiert hat. ("Du kommst hier nicht rein!")Erst mit erfolgreicher .1x Authorisierung bekommt der Client Zugang. Nach deiner (unbekannten) Syntax zu urteilen gilt dabei (geraten):
- aaa port-access authenticator 3 auth-vid 200 = Authentisierte Clients ohne dynamische VLAN ID vom Radius landen per Default im VLAN 200
- aaa port-access authenticator 3 unauth-vid 666 = Nicht authentisierte Clients landen per Default im VLAN 666. Das erklärt auch warum ein unauthentisierter Client im VLAN 666 landet wie du oben beschreibst.
Deine CLI "show" Outputs bestätigen das Verhalten. Sieht also so aus, das abgesehen vom richtigen VLAN Handling des vSwitches, die Radius Authentisierung an sich mehr oder minder klappt.
Wenn du den Freeradius mit "freeradius -X" im Debugging Mode laufen lässt kannst du das auch live sehen was vom und zum Switch geht!
bleibt die IP des VLAN-666 (aka Gummizelle) und die Netzwerkverbindung bestehen.
Lasse den Freeradius dafür unbedingt einmal im Debugging Mode laufen!Damit kann man wasserdicht checken ob der Radius das Attribut mit der VLAN ID an den Switch übermittelt.
Wenn ja, dann ist es ein Fehler im Switch (ggf. Fehlkonfiguration) das der die vom Radius übermittelte VLAN ID nicht korrekt auf seinen Port anwendet.
Denn der *1x-Port an sich ist ja untagged.
Das ist grundsätzlich erstmal richtig und üblicher Standard. Dot1x Ports sind ja im allgemeinen Access Ports die Endgeräte mit untagged Traffic bedienen.Es gibt aber Hersteller wie Ruckus u.a. denen man auch einen Tagged Flag mitgeben kann indem man als VLAN ID ein "T:200" vor der VLAN ID mitgibt. Ein Ruckus ICX Switch setzt den Port dann auf Tagged.
Lässt man es weg dann nimmt der ICX immer ein "U:200" an und setzt den Port untagged ins VLAN 200. Das ist aber Hersteller spezifisch und nicht alle Hersteller supporten sowas.
Jedoch wechselt er nach dem Radius-Login nicht das VLAN...
Da gilt es jetzt herauszufinden ob es am Radius oder Switch liegt. Der Debugging Mode ist dein Freund! 😉
Hier kannst du sehen wie es mit der VLAN ID 11 an einem Cisco Catalysten fehlerfrei funktioniert:
Hier kann man schon vorab erkennen das der Radius Server sauber die VLAN Attribute mitgibt! (Attribute Dump)

Auch hier, wie zu erwarten, der Reply des Radius mit den VLAN Attributen aus der SQL Datenbank und dem finalen "Access Accept" inklusive der VLAN Attribute! (Zeilen 12-14)
Port Konfig:
Show Output der Port Authentisierung
Hier sieht man das der Port 0/1 dem VLAN 11 zugeordnet wurde. Auch erwartbar, da die oigen Checks schon einwandfrei gezeigt haben das die VLAN Attribute mitkommen.
Der Cisco hat einen Debug Mode an Bord mit dem man den Authentisierungsprozess auch auf dem Switch genau ansehen kann:
Zeile 5 spricht für sich selber. 
Fazit:
Works as designed!! 👍 😉
Zu deinen Punkten...
Bei MAB oder auf WLAN Adaptern ist das unter Winblows NICHT erforderlich.
Allerdings gibt es hier einen Wermutstropfen weil EAP-MD5 große Einschränkungen hat. Zitat:
"EAP-MD5 is an authentication method that uses a challenge-response protocol, but it lacks encryption and doesn't offer mutual authentication or dynamic keys. While it can be used for basic authentication, it's not ideal for secure environments where dynamic VLAN assignment is crucial"
Unter normalen Umständen scheitert also eine dyn. VLAN Zuweisung damit. Man kann EAP-MD5 in einem PEAP Tunnel übertragen aber ob der Switch dann eine dyn. VLAN Zuweisung umsetzen kann ist mehr als fraglich.
Es ist sehr verwunderlich das deine Switch Hardware auf EAP-MD5 limitiert ist da PEAP seit Jahrzehnten dort Standard ist. Heute supportet jeder Chinesen Switch vom Blödmarkt diese Funktion. Der o.a. Catalyst ist fast 20 Jahre alt und kann das wie so gut wie alle LAN Switches problemlos.
Den Radius Check mit dem NTRadPing Tool solltest du immer vorab machen.
Aber auch an deinem Freeradius Debugging Output oben kannst du ja ganz klar sehen das dein Radius Server die VLAN ID Attribute zurückgibt. Aus Sicht des Radius Servers ist das also absout OK. NTRadPing wird das dann ebenso im Attribute Dump anzeigen.
Der böse Buhmann ist dein Switch der das scheinbar nicht oder nicht richtig am Port umsetzt!
Hier kann man schon vorab erkennen das der Radius Server sauber die VLAN Attribute mitgibt! (Attribute Dump)

Auch hier, wie zu erwarten, der Reply des Radius mit den VLAN Attributen aus der SQL Datenbank und dem finalen "Access Accept" inklusive der VLAN Attribute! (Zeilen 12-14)
(1) sql: --> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'VLAN-11' ORDER BY id
(1) sql: Executing select query: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'VLAN-11' ORDER BY id
(1) sql: Group "VLAN-11": Merging reply items
(1) sql: Tunnel-Type := VLAN
(1) sql: Tunnel-Medium-Type := IEEE-802
(1) sql: Tunnel-Private-Group-Id := "11"
rlm_sql (sql): Released connection (3)
(1) } # post-auth = ok
(1) Login OK: [vlan11] (from client lab-network1 port 0)
(1) Sent Access-Accept Id 5 from 10.1.10.222:1812 to 10.1.10.199:57476 length 36
(1) Tunnel-Type = VLAN
(1) Tunnel-Medium-Type = IEEE-802
(1) Tunnel-Private-Group-Id = "11"
(1) Finished request
Port Konfig:
interface FastEthernet0/1
description Authentication Dot1x only
switchport mode access
authentication event fail retry 0 action authorize vlan 98
authentication port-control auto
authentication periodic
dot1x pae authenticator
spanning-tree portfast
Show Output der Port Authentisierung
Hier sieht man das der Port 0/1 dem VLAN 11 zugeordnet wurde. Auch erwartbar, da die oigen Checks schon einwandfrei gezeigt haben das die VLAN Attribute mitkommen.
CiscoSW#show authentication int fa0/1
Client list:
Interface MAC Address Method Domain Status Session ID
Fa0/1 8cae.4cfe.0194 Dot1x DATA Authz Success 0A010A0600000002002
CiscoSW#show vlan | include 11
11 VLAN-11 active Fa0/1
Der Cisco hat einen Debug Mode an Bord mit dem man den Authentisierungsprozess auch auf dem Switch genau ansehen kann:
May 28 08:25:05.431: AUTH-EVENT (Fa0/1) Set new linksec data (handle 0xB3000003) NULL data
May 28 08:25:05.431: AUTH-EVENT (Fa0/1) Signalling Authc success for client 8cae.4cfe.0194
May 28 08:25:05.431: AUTH-EVENT (Fa0/1) Authorized client count: 0
May 28 08:25:05.431: AUTH-EVENT (Fa0/1) Authorized client count: 0
May 28 2025 08:25:05 CEST: %AUTHMGR-5-VLANASSIGN: VLAN 11 assigned to Interface Fa0/1 AuditSessionID 0A010A0600000003003E610F
May 28 08:25:05.431: AUTH-EVENT (Fa0/1) Setting vlan to 11 on DATA Vlan
May 28 08:25:05.431: AUTH-EVENT (Fa0/1) Signalling Authz success for client 8cae.4cfe.0194
May 28 08:25:06.471: AUTH-EVENT (Fa0/1) New IP: 10.11.1.150 for client 8cae.4cfe.0194
Fazit:
Works as designed!! 👍 😉
Zu deinen Punkten...
Auf dem Windows Klienten habe ich gar keine Einstellungen vorgenommen.
Das ist etwas ungewöhnlich, denn zu mindestens auf den Windows LAN Adaptern ist es per Default deaktiviert. Hier musst du immer manuell den Dienst "Automatische Konfiguration (verkabelt)" VORHER starten:
Der Switch kann an sich nur MD5
Das ist kein Problem, der Freeradius supportet auch MD5. Am Cisco Catalysten kann man das dediziert mit mab eap am Port umstellen.Allerdings gibt es hier einen Wermutstropfen weil EAP-MD5 große Einschränkungen hat. Zitat:
"EAP-MD5 is an authentication method that uses a challenge-response protocol, but it lacks encryption and doesn't offer mutual authentication or dynamic keys. While it can be used for basic authentication, it's not ideal for secure environments where dynamic VLAN assignment is crucial"
Unter normalen Umständen scheitert also eine dyn. VLAN Zuweisung damit. Man kann EAP-MD5 in einem PEAP Tunnel übertragen aber ob der Switch dann eine dyn. VLAN Zuweisung umsetzen kann ist mehr als fraglich.
Es ist sehr verwunderlich das deine Switch Hardware auf EAP-MD5 limitiert ist da PEAP seit Jahrzehnten dort Standard ist. Heute supportet jeder Chinesen Switch vom Blödmarkt diese Funktion. Der o.a. Catalyst ist fast 20 Jahre alt und kann das wie so gut wie alle LAN Switches problemlos.
Switch ist aus 192.168.20.0, seit dem der Switch Port getaggt ist, nicht mehr erreichbar / pingbar
Nur nochmal zur Klarstellung: Ein Dot1x oder MAB Port für Endgeräte, egal ob mit oder ohne dyn. VLAN Zuweisung, darf keinesfalls getagged werden!! Dot1x oder MAB Ports sind IMMER ungetaggt. Logisch, denn daran werden ja immer ungetaggte Endgeräte betrieben. Nicht das du hier etwas falsch verstanden hast!!Den Radius Check mit dem NTRadPing Tool solltest du immer vorab machen.
Aber auch an deinem Freeradius Debugging Output oben kannst du ja ganz klar sehen das dein Radius Server die VLAN ID Attribute zurückgibt. Aus Sicht des Radius Servers ist das also absout OK. NTRadPing wird das dann ebenso im Attribute Dump anzeigen.
Der böse Buhmann ist dein Switch der das scheinbar nicht oder nicht richtig am Port umsetzt!
Insofern kann ich den Switch-Port also fremdsteuern ??
WIE ist die Frage gemeint? Das du den Port grundsätzlich öffnen kannst mit der Authentisierung oder das du ein VLAN dynamisch dem Port zuweisen kannst?? 🤔Das der durch Dot1x geblockte Port grundsätzlich mit der Radius Authentisierung geöffnet wird ist eins der klassischen Grundmerkmal von .1x. Das muss man sicherlich nicht hinterfragen.
Die dynamische VLAN Zuweisung über die Radius Attribute eigentlich auch. Das ist ebenso klassischer Standard. Man kann ja grundsätzlich bei Radius noch viel mehr Attribute zuweisen. Z.B. eine 2stufige Authentisierung mit .1x und MAB erzwingen usw. usw.
Grundsätzlich gilt folgende Logik:
Wenn du kein statisches VLAN an einem Dot1x Port zuweist liegt auch ein so ein Port im Default ja immer untagged im VLAN 1 dem Default VLAN.
Ein User der ohne dynamische VLAN Attribute authentisiert wird, sprich also nur als einfacher User landet dann in diesem VLAN 1.
Legst du den Port ins VLAN xy dann landet dieser User nach der Authentisierung erwartungsgemäß im VLAN xy. Solange der Radius keine anderen Attribute liefert macht der Port dann was ihm statisch über die lokale Portkonfig gesagt wurde.
Liefert der Radius aber VLAN Attribute mit für die dynamische VLAN Zuweisung, dann "überrennen" diese Attribute die statische Port Zuweisung und wenden das VLAN vom Radius an.
Mit anderen Worden: Die Radius VLAN Informationen zu einer Authentisierung haben immer Priorität über statische Port Zuweisungen!
An einem Dot1x Port macht das auch durchaus Sinn, weil Radius hier immer die "höhere" Instanz ist.
Aber das Captive Portal schubst nicht in das VLAN
Auch das ist leider wieder etwas verwirrend was du damit genau meinst??Ein Captive Portal ist ja grundsätzlich fest über die Konfig auf ein VLAN gebunden. Das ist immer statisch und nie dynamisch veränderbar.
Klar und auch verständlich weil das CP ja in der Regel auf einem externen Gerät wie Firewall usw. liegt. Aber auch einige Switches die eine Web Authentisierung supporten auf einem VLAN sind über die Switchkonfig fest auf dieses eine VLAN gemappt. Diese Konfig hat nichts mit der Dot1x Konfig, Radius etc. zu tun und ist immer völlig unabhängig davon.
Das CP kann also niemals irgendwie dynamisch "geschubst" werden, geschweige denn kann selber "schubsen".
Willst du nun unauthorisierte Nutzer wie z.B. Gäste usw. in ein "Zwangs VLAN" packen geht das über die 2 schon oben beschriebenen Optionen:
- Radius hat ein Default Profil was allen unauthorisierten Usern das VLAN Attribut xy zuweist und diese Nutzer dann über die dynamische VLAN Zuweisung am Switchport zwangsweise in das VLAN packt. Wie gesagt spielt dann hier eine ggf. vorhandene statische VLAN Zuweisung am Port keine Rolle, weil die Radius Attribute diese "überstimmen" da höhere Prio.
- Über den Switch selber. Der Switch reagiert dann nur auf ein "Access DENY" des Radius und sobald das kommt und ein sog. "Auth. Fail VLAN xy " am Port konfiguriert ist (Cisco z.B.: authentication event fail retry 0 action authorize vlan xy) schmeisst der Switch das ins VLAN xy.
Eigentlich alles eine sehr einfache Logik! 😉
Ich habe den Debug-Modus gefunden, er ist nicht so ganz inhaltsreich.
Auch hier wieder der Doppeldeutigkeit halber die Nachfrage: Du meinst deinen Switch und dessen Debug Option, oder?? 🤔Die Freeradius Debug Option ist bekanntlich eins der besten Tools beim Security Troubleshooting mit Dot1x, MAB und Radius!!
Na es geht doch darum wie ich aus dem zugewiesen "Auth. Fail VLAN xy" nach der Autorisierung am Radius gerade über Captive Portal in ein neues VLAN komme.
Das kommt darauf an was dein eigentliches Ziel ist. Dot1x und CP sind ja eigentlich 2 getrennte Dinge die per se nichts miteinander zu tun haben werden aber oft zusammen genutzt, da hast du Recht, keine Frage.
Wobei Dot1x bzw. die dynamische VLAN Zuweisung primär dafür verantwortlich ist das Endgerät überhaupt erstmal sicher in das dazu erforderliche VLAN zu bringen. Also das reine Layer 2 Handling. Nicht mehr und nicht weniger...
Das Captive Portal ist dann für die L3 Connectivity zuständig. Fast immer auch in Verbindung mit DHCP, sprich der IP Adressierung. HIER am Beispiel der CPS auf den bekannten Firewalls OPNsense oder pfSense.
Du hast Recht, wenn du beides kombinieren willst oder musst ist es natürlich essentiell wichtig primär erstmal wichtig das die dynamischen VLAN Zuordnung funktioniert.
Dabei ist es erstmal egal ob das über Dot1x oder MAB via Radius VLAN Attribute oder über die Switchfunktion realisiert wird.
Einzig und allein zählt das ein nicht authorisiertes Endgerät in genau dem VLAN landet in der sich auch das Captive Portal befindet. Damit das CP also funktioniert ist es also essentiell das Endgeräte in dem betreffenden VLAN landet. Diese Funktion ist also essentiall für den CP Betrieb.
Diese Funktion ist übrigens völlig unabhängig vom Client. Ob du das also mit Winblows egal ob 10 oder 11, Mac OS, Linux oder Smartphones machst ist für die Funktion völlig irrelevant.
ich lande im VLAN 200, der offensichtlich von Radius übergeben wird.
Würde ja bedeuten das deine dynamische VLAN Zuweisung problemlos und korrekt funktioniert sofern der Switchport nicht statisch in das VLAN 200 konfiguriert wurde und es auch dann klappt wenn du das VLAN 200 im Radius testweise mal auf 300 änderst und der Port dann beim gleichen User in 300 liegt.Dein "offensichtlich" macht allerdings etwas stutzig?! Bist du dir über die Funktion unsicher? Wenn ja, warum?? Du kannst das doch wasserdicht verifizieren.
Zum testen habe ich das VLAN 200 als auth-vid vom Switch zuvor entfernt, trotzdem wurde der Port auf VLAN 200 geschaltet.
Das ist gut, denn das ist das erwartbare Verhalten.Du kannst es querchecken indem du a. den Login Namen einmal bewusst falsch schreibst, dann sollte der Port dicht bleiben. Zusätzlich einmal zum User die VLAN ID ändern. Wenn der Port sich dann in dem geänderten VLAN befindet arbeitet dein Switch wie er soll.
Und jetzt ist eben die Frage worauf es beim CP ankommt; warum die VLAN Angaben nicht am Switch ankommen - gesendet werden sie ja
Nochmal: Das CP selber hat mit dem VLAN oder auch dem dynamischen VLAN bzw. Dot1x und Radius nicht das Geringste zu tun. Es weiss gar nichts von VLANs.CPs befinden sich fast immer auf Routern oder Firewalls, also L3 Devices und "lauschen" auf Port TCP 80 und 443 Traffic. Ist ein Router Interface (eine Firewall ist auch ein Router) mit einem aktiven CP konfiguriert forwardet dieses Interface keinen Traffic mit Ausnahme von DHCP und DNS. Sobald ein Endgerät TCP 80 oder 443 Traffic sendet und das CP dies "sieht", triggert es als Antwort darauf die eigene Portalseite die die Authentisierungsdaten abfragt.
Diese können statisch sein, ein Einmaltoken oder können auch wieder von einem Radius kommen. Die CP Authentisierung ist völlig unabhängig von der der dyn. VLANs.
Kann der User sich im CP authentisieren landen die Mac Adressen dieser Endgeräte in der Forwarding Tabelle des CPs. Ohne Authentisierung nicht und das CP blockt weiter den Traffic.
Auch das eigentlich eine einfache Logik.
Dot1x oder MAB Switch und CP haben also per se erstmal nichts miteinander zu tun. Ausnahme sind L3 Switches die eine onboard Web Authentisierung supporten.
Die Frage worauf es beim CP ankommt stellt sich doch eigentlich gar nicht. Port Authentisierung und CP sind 2 getrennte Baustellen wenn dyn. VLAN Switch und CP auf unterschiedlichen Komponenten liegen wie (vermutlich) bei dir.
Wenn es das als Lösung war bitte deinen Thead dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?