OPNSense FreeRadius Server-MAC Authentication-dynamische VLAN Zuweisung
Hallo liebe Leute.
bin ziemlich neu in der OPNSense/freien Switch Welt, habe jetzt einmal, bevor ich mein ganzes Netzwerk umstelle ein Testsetting aufgebaut und stoße hier auf ein Problem beim Thema dynamische VLAN Zuweisung mittels Mac Authentication.
Zuerst mal ein bisschen zu meiner Vorgeschichte.
Komme von einem Unifi System und hatte dort diverse VLANs mit einer dynamischen Zuweisung mittels Radius/MAC Authentifizierung. Hat alles soweit wunderbar funktioniert, sowohl auf den Switches als auch auf den APs.
Möchte jetzt aber komplett weg von dem Unifi System, hin zu einem offenen und flexibleren System und habe mir hierzu auf einem PC OPNSense installiert und als Switche bzw. APs verwende ich Zyxel Geräte. Ich weiß hier gibt es die Nebula Oberfläche wo dies wahrscheinlich recht einfach ginge aber ich möchte die einzelnen Geräte Stand Alone betreiben. Das hat den Hintergrund, da ich wahrscheinlich später auch den ein oder anderen nicht Nebula fähigen Switch brauche und ich spätestens dann sowieso ein "Konfigurationsproblem" hätte. Deswegen will ich es gleich alles Standalone konfigurieren um es später einfacher zu haben.
Was ich bisher konfiguriert habe bzw. was bereits funktioniert:
Auf dem Zyxel Switch ist der Radius aktiviert und konfiguriert (IP, Ports und Shared Secret der OPNSense), es sind die VLANs angelegt und den Ports wie folgt zugewiesen (VID1 ist Standardmäßig vom Zyxel):
Wenn ich jetzt am Switch ein Lan Kabel anstecke passiert folgendes:
Was habe ich hier den vergessen oder falsch konfiguriert?
Was mir (in den Logs) noch so aufgefallen ist:
Habt ihr eine Idee woran es liegen könnte oder was hier falsch konfiguriert sein könnte.
Vielen Dank schonmal und LG
Patrick
bin ziemlich neu in der OPNSense/freien Switch Welt, habe jetzt einmal, bevor ich mein ganzes Netzwerk umstelle ein Testsetting aufgebaut und stoße hier auf ein Problem beim Thema dynamische VLAN Zuweisung mittels Mac Authentication.
Zuerst mal ein bisschen zu meiner Vorgeschichte.
Komme von einem Unifi System und hatte dort diverse VLANs mit einer dynamischen Zuweisung mittels Radius/MAC Authentifizierung. Hat alles soweit wunderbar funktioniert, sowohl auf den Switches als auch auf den APs.
Möchte jetzt aber komplett weg von dem Unifi System, hin zu einem offenen und flexibleren System und habe mir hierzu auf einem PC OPNSense installiert und als Switche bzw. APs verwende ich Zyxel Geräte. Ich weiß hier gibt es die Nebula Oberfläche wo dies wahrscheinlich recht einfach ginge aber ich möchte die einzelnen Geräte Stand Alone betreiben. Das hat den Hintergrund, da ich wahrscheinlich später auch den ein oder anderen nicht Nebula fähigen Switch brauche und ich spätestens dann sowieso ein "Konfigurationsproblem" hätte. Deswegen will ich es gleich alles Standalone konfigurieren um es später einfacher zu haben.
Was ich bisher konfiguriert habe bzw. was bereits funktioniert:
- 1 LAN (123er IPs) und 2 VLANs (VID124 und VID125) in OPNSense angelegt und als Parent Interface das LAN Interface zugewiesen.
- DHCP für die VLANs ist angelegt
- Freeradius installiert, aktiviert (VLAN Zuweisung unter General ist auch aktiviert), unter Clients ist der Switch mit "SWITCH01" mit der dazugehörigen IP konfiguriert und ein zweiter Eintrag mit 127.0.0.1 für die OPNSens, unter Users ist ein User angelegt mit der MAC als Benutzername und Passwort und bei VLAN ID steht 124 drin
- Unter System/Access/Servers ist Eintrag mit den Einstellungen 127.0.0.1, Type Radius, Authentication und Accounting sowie den dazugehörigen Ports 1812 und 1813 eingerichtet
Auf dem Zyxel Switch ist der Radius aktiviert und konfiguriert (IP, Ports und Shared Secret der OPNSense), es sind die VLANs angelegt und den Ports wie folgt zugewiesen (VID1 ist Standardmäßig vom Zyxel):
- Port2: VID1 Forbidden, VID124 Fixed (Untagged), VID125 Forbidden - PVID124, Ingress Check aktiviert, Frame Typ All
- Port3: VID1 Forbidden, VID124 Forbidden, VID125 Fixed (Untagged) - PVID125, Ingress Check aktiviert, Frame Typ All
- Port4: VID1 Fixed (Tagged), VID124 Fixed (Tagged), VID125 Fixed (Tagged) - PVID1 - Mac Authentication aktiviert, Ingress Check aktiviert, Frame Typ All
- Port10 (Upload Port zur OPNSense): VID1 Fixed (Untagged), VID124 Fixed (Tagged), VID125 Fixed (Tagged) - PVID1, Trunk aktiviert, Ingress Check aktiviert, Frame Typ All
Wenn ich jetzt am Switch ein Lan Kabel anstecke passiert folgendes:
- Port2 (PVID124): PC bekommt eine DHCP IP aus dem 124er Netz -> Passt also
- Port3 (PVID125): PC bekommt eine DHCP IP aus dem 125er Netz -> Passt also
- Port4 (MAC Authentication): im Log File vom Freeradius steht "Auth1) Login OK: [MACAdresse/MACAdresse] (from Client Switch01 port 0), PC bekommt aber eine Adresse aus dem 123er LAN Netz -> Passt nicht
Was habe ich hier den vergessen oder falsch konfiguriert?
Was mir (in den Logs) noch so aufgefallen ist:
- Lösche ich den User aus der OPNSense kommt ebenso die Meldung mit Auth Login OK und bekomme eine 123er IP. Also hier dürfte schonmal was nicht stimmen, ich habe aber irgendwie nichts gefunden.
- Stelle ich beim Zyxel Switch nur die MAC Authentication ein bekomme ich eine 123er IP, stelle ich zusätzlich 802.1X ein bekomme ich garkeine IP, solange ich nicht im jeweiligen Netzwerkadapter aktiv 802.1X aktiviere und mich mit einem Benutzer den ich vorher in der OPNSense angelegt habe anmelde (das funktioniert dann aber zumindest und ich bekomme die IP aus dem VLAN welches ich beim Benutzer eingetragen habe).
Habt ihr eine Idee woran es liegen könnte oder was hier falsch konfiguriert sein könnte.
Vielen Dank schonmal und LG
Patrick
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4157490863
Url: https://administrator.de/forum/opnsense-freeradius-server-mac-authentication-dynamische-vlan-zuweisung-4157490863.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
20 Kommentare
Neuester Kommentar
Guckst du dazu auch hier:
Freeradius Management mit WebGUI
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Mikrotik - mehrere VLANs auf cAP AC mit CAPsMAN
Mikrotik - dyn-vLAN und MAC-auth in ROS 7.2
Cisco SG 350x Grundkonfiguration
Ruckus ICX - 802.1x - is mac-vlan member of 2 vlans in single-untagged mode
Praxisthreads hier die sich zwar auf die pfSense beziehen aber der Unterschied ist kosmetisch, da als Unterbau bei beiden ein FreeRadius werkelt findest du in den weiterführenden Links des o.a. Tutorials.
Idealerweise stoppt man über den Shellzugriff der OPNsense den Freeradius und startet ihn dananch manuel neu im Debugging Mode mit -X in der Konsole. Dann zeigt er dir sehr genau wo und warum eine Authentisierung scheitert.
Zu deinen 2 Punkten die dir aufgefallen sind:
1.)
Du hast eine Default Authentication dann aktiviert indem dein letzter Eintrag sowas wie das hier in der user.conf zeigt:
("Tunnel" Parameter sind nur bei dynamischer VLAN Zuweisung relevant!)
Das bedeutet das alle User authentisiert werden bzw. mit dem o.a. Default Eintrag auch die die nicht explizit in der Radius Konfig definiert sind. Gastuser etc.
Denen wird dann im Beispiel oben das VLAN 10 zugewiesen. In der regel ist das dann immer ein sog. Captive Portal WLAN also ein Gastsegment indem eine Web basierte Authentisierung mit Einmal Passwörtern, Vouchern etc. ermöglicht wird. Ein übliches Standard Design.
Wenn du, wie du oben schreibst, dort falsche IP Adressen bekommst wird dynamisch eine falsche VLAN ID zugewiesen aus deren Bereich der Client dann eine IP bekommt.
Wenn du nicht mit dynamischer VLAN Zuweisung arbeitest bestimmt einzig und allein deine statische VLAN Zuweisung in der Switch Konfig welches VLAN hier nach der Authentisierung aktiv ist.
Klappt also bei einer statischen Zuweisung die Port Authentisierung aber du bekommst eine falsche IP ist deine Switch VLAN Konfiguration fehlerhaft!
2.)
Bei gleichzeitiger Mac und .1x Authentisierung an einem Port musst du aufpassen.
Die meisten der Billighersteller supporten sowas nicht, du musst also im Datenblatt checken ob Zyxel sowas überhaupt kann.
Bei den Herstellern die es supporten muss man in der Konfig dann zwingend angeben
Ports mit eine Dual Authentication sind also nicht trivial und erfordern einen deutlichen Mehraufwand in der Konfiguration bzw. Überlegungen der Verfahren. Das solltest du auf dem Radar haben.
Freeradius Management mit WebGUI
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Mikrotik - mehrere VLANs auf cAP AC mit CAPsMAN
Mikrotik - dyn-vLAN und MAC-auth in ROS 7.2
Cisco SG 350x Grundkonfiguration
Ruckus ICX - 802.1x - is mac-vlan member of 2 vlans in single-untagged mode
Praxisthreads hier die sich zwar auf die pfSense beziehen aber der Unterschied ist kosmetisch, da als Unterbau bei beiden ein FreeRadius werkelt findest du in den weiterführenden Links des o.a. Tutorials.
Idealerweise stoppt man über den Shellzugriff der OPNsense den Freeradius und startet ihn dananch manuel neu im Debugging Mode mit -X in der Konsole. Dann zeigt er dir sehr genau wo und warum eine Authentisierung scheitert.
Zu deinen 2 Punkten die dir aufgefallen sind:
1.)
Du hast eine Default Authentication dann aktiviert indem dein letzter Eintrag sowas wie das hier in der user.conf zeigt:
DEFAULT Cleartext-Password := "%{User-Name}"
Tunnel-Type = 13,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-Id = 10
Das bedeutet das alle User authentisiert werden bzw. mit dem o.a. Default Eintrag auch die die nicht explizit in der Radius Konfig definiert sind. Gastuser etc.
Denen wird dann im Beispiel oben das VLAN 10 zugewiesen. In der regel ist das dann immer ein sog. Captive Portal WLAN also ein Gastsegment indem eine Web basierte Authentisierung mit Einmal Passwörtern, Vouchern etc. ermöglicht wird. Ein übliches Standard Design.
Wenn du, wie du oben schreibst, dort falsche IP Adressen bekommst wird dynamisch eine falsche VLAN ID zugewiesen aus deren Bereich der Client dann eine IP bekommt.
Wenn du nicht mit dynamischer VLAN Zuweisung arbeitest bestimmt einzig und allein deine statische VLAN Zuweisung in der Switch Konfig welches VLAN hier nach der Authentisierung aktiv ist.
Klappt also bei einer statischen Zuweisung die Port Authentisierung aber du bekommst eine falsche IP ist deine Switch VLAN Konfiguration fehlerhaft!
2.)
Bei gleichzeitiger Mac und .1x Authentisierung an einem Port musst du aufpassen.
Die meisten der Billighersteller supporten sowas nicht, du musst also im Datenblatt checken ob Zyxel sowas überhaupt kann.
Bei den Herstellern die es supporten muss man in der Konfig dann zwingend angeben
- Welches Verfahren man zuerst ausführen möchte und welches hinterher und
- Ob man nach dem ersten Success zwingend noch das 2te Verfahren ausführen will oder nicht
Ports mit eine Dual Authentication sind also nicht trivial und erfordern einen deutlichen Mehraufwand in der Konfiguration bzw. Überlegungen der Verfahren. Das solltest du auf dem Radar haben.
weil nicht genau dokumentiert ist ob man das für die MAC Authentifizierung aktivieren muss oder nicht.
Muss man nicht! Das eine bedingt niemals die Funktion des anderen und ist immer nur Port bezogen.Sprich man muss pro Port im Setup bestimmen ob man da MAP (Mac Auth Bypass) oder Dot1x macht oder eine Kombination von beidem. (Letzteres sofern supportet)
Die Konfigs von z.B. Cisco und Ruckus im o.a. Link zeigen diese Konfig Logik einer Kombination.
Ich möchte rein nur dynamische VLAN Zuweisung über die OPNSense.
Was ja generell eine Lachnummer ist und schnell implementiert ist.Kardinalsfrage ist aber immer: Nur MAP (Mac Auth Bypass), nur 802.1x oder eine Kombination? Letzteres sofern supportet auf der HW).
Dazu machst du ja leider keinerlei konkrete Aussagen, ist aber wichtig für das Setup bzw. weitere Vorgehen. Vielleicht solltest du dir darüber erstmal klar werden?! 😉
laut deiner Beschreibung ist es nur MAB was ich brauche.
Meine Sicht der Dinge ist ja irrelevant. Es zählt das was DU in deinem Netz umsetzen willst und danach richtet sich die Konfig! 😉ob die MAC Adresse vorhanden ist, wenn ja dann Zack ab mit dem Gerät ins hinterlegt VLAN, wenn nicht dann ab in ein Fallback VLAN
Das ist kinderleicht und schnell erledigt. In der User Konfig Datei muss dann sowas wie:00:22:FA:7B:12:34 Cleartext-Password := "00:22:FA:7B:12:34"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = 20
DEFAULT Cleartext-Password := "%{User-Name}"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = EEE-802,
Tunnel-Private-Group-Id = 99
WICHTIG:
Unbedingt auf das Format der Mac Adresse achten was im Setup des Authenticators (Switch) eingestellt ist!! Für den Radius Server sind 00:22:FA:7B:12:34, 00:22:fa:7b:12:34, 00-22-FA-7B-12-34 oder 0022FA7B1234 vier völlig unterschiedliche User!!
Framed PPP ist auch falsch, denn das gibt es bei MAB oder 802.1x nicht und ist definitiiv das falsche Format. Da hast du also irgendeinen Haken falsch gesetzt im Setup!
Relevant ist hier nur in welchem Format der Zyxel das schickt!
Ich kann aber auch nichts überschreiben.
Das ist falsch. Wenn du das Filesystem auf RW setzt geht es aber solche Frickelei ist gar nicht nötig, denn der OPNsense FreeRadius macht das auch so richtig wenn das Setup stimmt.Habe Username und Passwort im Radius und Switch so eingestellt das er Kleinbuchstaben nimmt und keine Trennzeichen.
Wenn das passt mit dem Format was der Zyxel schickt ist das OK. Wenn nicht hast du Pech.Relevant ist hier nur in welchem Format der Zyxel das schickt!
Ein paar Tests mit dem OPNsense FreeRadius Plugins brachten es ans Licht....
Man sieht es wenn man den Radius Server auf der OPNsense Firewall in den Debug Mode versetzt. Das ist schnell gemacht auf der OPNsense.
Testswitch ist hier ein Cisco Catalyst 2960 und ein Ruckus ICX 7150 sowie einige Cisco WLAN APs mit IP .111.102 und einfacher MAB Auth Port Konfig:
!
radius server radius
address ipv4 192.168.111.103 auth-port 1812 acct-port 1813
key testing123
!
interface FastEthernet0/1
description Port Authentication Mac only
switchport mode access
authentication port-control auto
authentication periodic
mab
spanning-tree portfast
!
Der Test mit einer klassischen FreeRadius Server Installation auf einem Debian Server mit folgender User Konfig:
ergibt erwartungsgemäß diesen debug Output:
(0) Received Access-Request Id 17 from 192.168.111.102:1645 to 192.168.111.103:1812 length 157
(0) User-Name = "8cae4cfe0194"
(0) User-Password = "8cae4cfe0194"
(0) Service-Type = Call-Check
(0) Framed-MTU = 1500
(0) Called-Station-Id = "00-17-5A-99-FA-01"
(0) Calling-Station-Id = "8C-AE-4C-FE-01-94"
(0) Message-Authenticator = 0xf61f38c493bfa820cc60053406e4a79c
(0) NAS-Port-Type = Ethernet
(0) NAS-Port = 50001
(0) NAS-Port-Id = "FastEthernet0/1"
(0) NAS-IP-Address = 192.168.111.102
...
(0) Sent Access-Accept Id 17 from 192.168.111.103:1812 to 192.168.111.102:1645 length 0
(0) Tunnel-Type = VLAN
(0) Tunnel-Medium-Type = IEEE-802
(0) Tunnel-Private-Group-Id = "10"
(0) Finished request
Zeigt das die VLAN Attribute zusammen mit dem Access Accept vom Radius Server sauber an den Switch rausgehen.
Was der Cisco und der Ruckus dann auch entsprechend quittieren mit "Success" und der korrekten VLAN Zuweisung (10):
Works as designed also und klassischer Standard wie es sein soll! 👍😉
Sieht man sich aber nun den Debug Output des OPNsense FreeRadius Plugins an fehlen diese VLAN Radius Attribute in der Access Accept Message!! 🤔
Eine Recherche in den OPNsense Dokus brachte es dann ans Licht...
Das FreeRadius Plugin schickt die VLAN Attribute einzig nur wenn EAP-TLS verwendet wird. Das unterscheidet das OPNsense Setup von einem klassischen FreeRadius der das im Default auch mit MD5, PEAP usw. macht.
Die Lösung ist dann aber recht einfach indem man im OPNsense Setup den EAP Default auf EAP-TLS setzt im FreeRadius Service Setup. PEAP dürfte ebenso klappen.
Und Tadaaa... Dann kommen bei der OPNsense auch sofort die VLAN Attribute mit: 🙂
Und das VLAN wird dann fehlerfrei am Port zugewiesen (siehe Cisco oben) und funktioniert dann auch bei allen anderen Herstellern auf Switch und WLAN APs mit Port Authentisierung und dynamischer VLAN Zuordnung.
Case closed...! 😉
Man sieht es wenn man den Radius Server auf der OPNsense Firewall in den Debug Mode versetzt. Das ist schnell gemacht auf der OPNsense.
- Im Setup temporär SSH Zugang für den Root User einrichten, einloggen und die Shell starten. (Danach den Shell Zugang wieder deaktivieren! (Security!))
- ps ax zeigt den Radius Daemon "25120 - Is 0:00.26 /usr/local/sbin/radiusd" den man dann mit kill 25120 stoppen kann. Etwas unschön aber zum Troubleshooten ok.
- Nun startet man mit /usr/local/sbin/radiusd -X den Radius manuell im Debug Mode und kann sich alles genau ansehen. (<ctrl> c stoppt ihn wieder)
Testswitch ist hier ein Cisco Catalyst 2960 und ein Ruckus ICX 7150 sowie einige Cisco WLAN APs mit IP .111.102 und einfacher MAB Auth Port Konfig:
!
radius server radius
address ipv4 192.168.111.103 auth-port 1812 acct-port 1813
key testing123
!
interface FastEthernet0/1
description Port Authentication Mac only
switchport mode access
authentication port-control auto
authentication periodic
mab
spanning-tree portfast
!
Der Test mit einer klassischen FreeRadius Server Installation auf einem Debian Server mit folgender User Konfig:
8cae4cfe0194 Cleartext-Password := "8cae4cfe0194"
Tunnel-Type = 13,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-Id = 10
(0) Received Access-Request Id 17 from 192.168.111.102:1645 to 192.168.111.103:1812 length 157
(0) User-Name = "8cae4cfe0194"
(0) User-Password = "8cae4cfe0194"
(0) Service-Type = Call-Check
(0) Framed-MTU = 1500
(0) Called-Station-Id = "00-17-5A-99-FA-01"
(0) Calling-Station-Id = "8C-AE-4C-FE-01-94"
(0) Message-Authenticator = 0xf61f38c493bfa820cc60053406e4a79c
(0) NAS-Port-Type = Ethernet
(0) NAS-Port = 50001
(0) NAS-Port-Id = "FastEthernet0/1"
(0) NAS-IP-Address = 192.168.111.102
...
(0) Sent Access-Accept Id 17 from 192.168.111.103:1812 to 192.168.111.102:1645 length 0
(0) Tunnel-Type = VLAN
(0) Tunnel-Medium-Type = IEEE-802
(0) Tunnel-Private-Group-Id = "10"
(0) Finished request
Zeigt das die VLAN Attribute zusammen mit dem Access Accept vom Radius Server sauber an den Switch rausgehen.
Was der Cisco und der Ruckus dann auch entsprechend quittieren mit "Success" und der korrekten VLAN Zuweisung (10):
Cat2960#sh authentication interface fa 0/1
Client list:
Interface MAC Address Method Domain Status Session ID
Fa0/1 8cae.4cfe.0194 mab DATA Authz Success C0A86F660000000F00572189
CiscoSW#sh vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/10, Fa0/13
Fa0/14, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Gi0/1, Gi0/2
10 VLAN-10 active Fa0/1
20 VLAN-20 active Fa0/8, Fa0/11, Fa0/12
30 VLAN-30 active Fa0/9
Sieht man sich aber nun den Debug Output des OPNsense FreeRadius Plugins an fehlen diese VLAN Radius Attribute in der Access Accept Message!! 🤔
(4) Received Access-Request Id 3 from 192.168.111.102:1645 to 192.168.111.1:1812 length 157
(4) User-Name = "8cae4cfe0194"
(4) User-Password = "8cae4cfe0194"
(4) Service-Type = Call-Check
(4) Framed-MTU = 1500
(4) Called-Station-Id = "00-17-5A-99-FA-01"
(4) Calling-Station-Id = "8C-AE-4C-FE-01-94"
(4) Message-Authenticator = 0x4bc7bacbd03a1a662c22323930792efd
(4) NAS-Port-Type = Ethernet
(4) NAS-Port = 50001
(4) NAS-Port-Id = "FastEthernet0/1"
(4) NAS-IP-Address = 192.168.111.102
...
(4) Sent Access-Accept Id 12 from 192.168.111.1:1812 to 192.168.111.102:1645 length 32
(4) Service-Type = Framed-User
(4) Finished request
Das FreeRadius Plugin schickt die VLAN Attribute einzig nur wenn EAP-TLS verwendet wird. Das unterscheidet das OPNsense Setup von einem klassischen FreeRadius der das im Default auch mit MD5, PEAP usw. macht.
Die Lösung ist dann aber recht einfach indem man im OPNsense Setup den EAP Default auf EAP-TLS setzt im FreeRadius Service Setup. PEAP dürfte ebenso klappen.
Und Tadaaa... Dann kommen bei der OPNsense auch sofort die VLAN Attribute mit: 🙂
(0) Sent Access-Accept Id 22 from 192.168.111.1:1812 to 192.168.111.102:1645 length 42
(0) Tunnel-Type = VLAN
(0) Tunnel-Medium-Type = IEEE-802
(0) Tunnel-Private-Group-Id = "10"
(0) Framed-Protocol = PPP
(0) Finished request
Case closed...! 😉
Du hast recht das VLAN Attribut kommt mit aber ich bekomme trotzdem eine 123er Adresse
Dann "erkennt" der Switch die Radius VLAN Attribute nicht. Das kann mehrere Gründe haben. Die wichtigsten:- Der Switch supportet keine dynamischen VLANs mit MAB oder Dot1x.
- Es gibt kein konfiguriertes VLAN mit der dynamischen ID auf dem Switch
- Du hast fälschlicherweise dem Port im Setup ein VLAN statisch zugewiesen?! Das darf nicht sein, denn alle dynamischen VLAN Ports müssen zwingend immer im Default VLAN stecken bzw. die Default Konfig haben! Es darf keinerlei statische Zuweisung da geben, ansonsten scheitert die dynamische Zuweisung! Ggf also das "Ingress Check" entfernen.
Ein Test dieser OPNsense Konfig mit den folgenden Switches: Cisco Catalyst, Cisco SG/CBS, Ruckus ICX, HP ProCurve, HP-1910 und Mikrotik CRS-305 verlief erfolgreich so das man davon ausgehen kann das es definitiv nicht an der Radius Konfig an sich liegt sondern an einem Konfig Fehler deinerseits auf dem Switch oder einem Fehlverhalten der Switch Firmware.
In der Zyxel Knowledgebase gibt es eine entsprechende Anleitung die alle Settings beschreibt:
https://support.zyxel.eu/hc/en-us/articles/4453007504658-Configuring-RAD ...
GVRP hat mit dynamischen VLANs nichts zu tun.
Das ist ein standartisiertes VLAN Registrierungs Protokoll wie das proprietäre VTP bei Cisco. Es bewirkt das VLANs die an einem Switch konfiguriert werden dynamisch und automatisch auch an alle anderen GVRP sprechenden VLAN Switches im Netz distribuiert werden.
Das hat keinerlei Einflüss auf eine dynmaische VLAN Portzuweisung mit MAB oder Dot1x.
Bei Cisco Switches gibt es einen Debug Kommando. Ein "debug mab all" z.B. zeigt dann auch auf dem Switch detailierte Debug Messages die genau beschreiben was auf der Switchseite abgeht. Ggf. hat Zyxel sowas ja auch zusätzlich zum Log oder Syslog?!
Das ist ein standartisiertes VLAN Registrierungs Protokoll wie das proprietäre VTP bei Cisco. Es bewirkt das VLANs die an einem Switch konfiguriert werden dynamisch und automatisch auch an alle anderen GVRP sprechenden VLAN Switches im Netz distribuiert werden.
Das hat keinerlei Einflüss auf eine dynmaische VLAN Portzuweisung mit MAB oder Dot1x.
Ich werde mal schauen das ich LOGs rauskriege
Das wäre das Wichtigste um zu sehen was da genau auf dem Switch abgeht.Bei Cisco Switches gibt es einen Debug Kommando. Ein "debug mab all" z.B. zeigt dann auch auf dem Switch detailierte Debug Messages die genau beschreiben was auf der Switchseite abgeht. Ggf. hat Zyxel sowas ja auch zusätzlich zum Log oder Syslog?!
Wenns das denn nun war bitte dann auch nicht vergessen deinen Thread hier als erledigt zu schliessen!
Moin'zam!
Diese Geschichte ist zwar schon ein bisschen in die Jahre gekommen, aber irgendwie fehlt mir hier das 'Happy End'.
Der Switch, welcher vom Fragesteller verwendet wird/wurde, bietet die gewünschte Funktion nicht an.
Auf der Hersteller-Website wird in der XGS-Serie unter Funktionen Folgendes beschrieben:
- 802.1x VLAN and bandwidth assignment by RADIUS*
Dies ist richtig. ABER nur wenn beides verwendet wird (Mac Auth via Radius + 802.1x). Heißt: VLAN's werden nur dann dynamisch zugewiesen, wenn clientseitig die Dot1x Authentifizierung aktiviert ist und Du mit USER = MAC & PASS = MAC um die Ecke kommst.
Klettert man bei Zyxel die Preisleiter etwas nach oben heißt das Ganze dann "MAC-based authentication per VLAN" und funktioniert so wie es soll. Die OPNSense kann in diesem Fall nichts dafür.
Ich hoffe diesen Thread damit unmissverständlich geschlossen zu haben.
Diese Geschichte ist zwar schon ein bisschen in die Jahre gekommen, aber irgendwie fehlt mir hier das 'Happy End'.
Der Switch, welcher vom Fragesteller verwendet wird/wurde, bietet die gewünschte Funktion nicht an.
Auf der Hersteller-Website wird in der XGS-Serie unter Funktionen Folgendes beschrieben:
- 802.1x VLAN and bandwidth assignment by RADIUS*
Dies ist richtig. ABER nur wenn beides verwendet wird (Mac Auth via Radius + 802.1x). Heißt: VLAN's werden nur dann dynamisch zugewiesen, wenn clientseitig die Dot1x Authentifizierung aktiviert ist und Du mit USER = MAC & PASS = MAC um die Ecke kommst.
Klettert man bei Zyxel die Preisleiter etwas nach oben heißt das Ganze dann "MAC-based authentication per VLAN" und funktioniert so wie es soll. Die OPNSense kann in diesem Fall nichts dafür.
Ich hoffe diesen Thread damit unmissverständlich geschlossen zu haben.