lordfire112
Goto Top

Pfsense FreeRadius VLANs per MAC zuweisen

Hallo Zusammen,

ich habe ein Problem wo ich nicht mehr weiter weiß, folgende Konstellation
Pfsense als Firewall, mit installiertem FreeRadius
Switche von Ubiquiti
Es gibt 4 VLANS, Default (1), Hotspot(99), Keller(90),Voip(8)

Über die Mac Adresse sollen nun die Notebooks, PC,s usw. in die entsprechenden VLANs zugewiesen werden.
Das funktioniert auch soweit für die VLANs 90,99,8 es funktioniert nicht für das VLAN 1.
Sobald ich einem Client über den Radius kein VLAN mitgebe (ist als Default eingestellt) oder das VLAN1
bekommt der Client zwar eine IP aus dem IP Bereich von VLAN 1 aber er hat keinerlei Netzwerkzugriff.

Weise ich dem gleichen Netzwerk Port das Default Vlan zu funktioniert alles ganz normal.

Hat jemand noch eine Idee?

Grüße

Content-Key: 6323082263

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

Printed on: April 28, 2024 at 13:04 o'clock

Member: aqui
aqui Mar 11, 2023, updated at May 15, 2023 at 14:51:01 (UTC)
Goto Top
bekommt der Client zwar eine IP aus dem IP Bereich von VLAN 1 aber er hat keinerlei Netzwerkzugriff.
Das Verhalten widerspricht sich aber etwas.
So ein 802.1x oder Mac Bypass gesicherter Switchport ist im Default nicht authorisiert, lässt also keinerlei eingehenden Traffic eines angeschlossenen Clients durch, was ja mit dieser Port Security auch genau gewollt ist das eben keine unauthorisierten Nutzer Zugang zum Netzwerk haben. Folglich können auch niemals DHCP Requests eines Clients durchkommen. Clients an solchen Ports haben ohne eine Authorisierung immer eine 169.254.x.y ZeroConf oder APIPA Adresse.
Siehe auch HIER.

Wenn du jetzt schreibst das der Port eine gültige IP Adresse aus dem Netz bekommen hat, ist das ein sicheres Indiz das der Client erfolgreich am Port authentisiert wurde und auch erfolgreich in das VLAN 1 geschoben wurde andernfalls hätte er ja niemals eine gültige IP von einem dortigen DHCP Server bekommen. Sollte man dann auch im Radius Log sehen können!
Daraus lässt sich aber wiederum schließen das dann zumindestens eine Kommunikation mit dem DHCP Server ja problemlos funktioniert. Wenn das aber funktioniert, muss auch die Kommunikation mit allen anderen Geräten klappen.
Es würde ja keinen Sinn machen wenn der Client fehlerlos mit dem DHCP Server in diesem Netz arbeiten kann aber nicht mit anderen Geräten. Das würde eher darauf hinweisen das ggf. IP Access- oder Firewall Regeln irgendwo aktiv sind.
Member: lordfire112
lordfire112 Mar 11, 2023 at 17:55:33 (UTC)
Goto Top
Das genau verstehe ich eben nicht.
Er bekommt eine IP aus dem richtigen VLAN aber kein Ping nichts geht

Firewall würde ich ausschließen da ich ja nicht mal den DHCP Server pingen kann

Ich bin echt ratlos
Member: commodity
commodity Mar 11, 2023 updated at 21:05:59 (UTC)
Goto Top
Switche von Ubiquiti
mag ich nicht. Den maßgeblichen Switch und Controller mal neu gestartet? Updatestand aktuell?

Vergibst Du das VLAN 1 im Radius tagged oder untagged? Vielleicht da was verwechselt?

Das hier ist nicht Dein Problem, aber vielleicht hilft's gegen die Ratlosigkeit:
https://community.ui.com/questions/Radius-setup-to-access-to-untagged-VL ...
Mit "a kind of bug" muss man da wohl ab und zu rechnen. Dafür ist alles schön bunt face-big-smile

Ansonsten: Rat gibt oft der Trace. Und das Log vom Radius.

Und:
Firewall würde ich ausschließen da ich ja nicht mal den DHCP Server pingen kann.
Die Aussage verstehe ich nicht. Mein erster Gedanke war auch "Firewall". Das ist aber deshalb unwahrscheinlich, weil Du ja bei statischer Vergabe Traffic hast, wenn ich Dich richtig verstehe. Kann aber natürlich sein, dass Du die DHCP-Range nicht freigegeben hast, z.B.

Viele Grüße, commodity
Member: lordfire112
lordfire112 Mar 12, 2023 updated at 14:06:04 (UTC)
Goto Top
Ich hab hier mal das Radius Log von der Anmeldung des Clients, das sieht doch unauffällig aus.
 Received Access-Request Id 1 from 192.168.9.17:57330 to 192.168.9.1:1812 length 161
(0)   User-Name = "4C526224E36D"  
(0)   Service-Type = Call-Check
(0)   Called-Station-Id = "24:5a:4c:12:17:3f"  
(0)   Calling-Station-Id = "4c:52:62:24:e3:6d"  
(0)   NAS-Port = 34
(0)   NAS-Port-Id = "Gigabitethernet 0/34"  
(0)   Framed-MTU = 1500
(0)   NAS-Port-Type = Ethernet
(0)   EAP-Message = 0x0200001101344335323632323445333644
(0)   NAS-IP-Address = 192.168.9.17
(0)   Message-Authenticator = 0x39f1f73ff69b419eb3c70d7a169c79cb
(0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(0)   authorize {
(0)     [preprocess] = ok
(0)     [chap] = noop
(0)     [mschap] = noop
(0)     [digest] = noop
(0) suffix: Checking for suffix after "@"  
(0) suffix: No '@' in User-Name = "4C526224E36D", skipping NULL due to config.  
(0)     [suffix] = noop
(0) ntdomain: Checking for prefix before "\"  
(0) ntdomain: No '\' in User-Name = "4C526224E36D", skipping NULL due to config.  
(0)     [ntdomain] = noop
(0) eap: Peer sent EAP Response (code 2) ID 0 length 17
(0) eap: EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize  
(0)     [eap] = ok
(0)   } # authorize = ok
(0) Found Auth-Type = eap
(0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(0)   authenticate {
(0) eap: Peer sent packet with method EAP Identity (1)
(0) eap: Calling submodule eap_md5 to process data
(0) eap_md5: Issuing MD5 Challenge
(0) eap: Sending EAP Request (code 1) ID 1 length 22
(0) eap: EAP session adding &reply:State = 0xbdb22fe8bdb32b2c
(0)     [eap] = handled
(0)   } # authenticate = handled
(0) Using Post-Auth-Type Challenge
(0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(0)   Challenge { ... } # empty sub-section is ignored
(0) Sent Access-Challenge Id 1 from 192.168.9.1:1812 to 192.168.9.17:57330 length 80
(0)   EAP-Message = 0x010100160410e7a13dd7ee2e3ce9190f76fe3bd57e6b
(0)   Message-Authenticator = 0x00000000000000000000000000000000
(0)   State = 0xbdb22fe8bdb32b2c72c518a33ab01589
(0) Finished request
Waking up in 4.9 seconds.
(1) Received Access-Request Id 2 from 192.168.9.17:57330 to 192.168.9.1:1812 length 184
(1)   User-Name = "4C526224E36D"  
(1)   Service-Type = Call-Check
(1)   Called-Station-Id = "24:5a:4c:12:17:3f"  
(1)   Calling-Station-Id = "4c:52:62:24:e3:6d"  
(1)   NAS-Port = 34
(1)   NAS-Port-Id = "Gigabitethernet 0/34"  
(1)   Framed-MTU = 1500
(1)   NAS-Port-Type = Ethernet
(1)   State = 0xbdb22fe8bdb32b2c72c518a33ab01589
(1)   EAP-Message = 0x0201001604102caaba41d5b50f5e3b6ea5dbe6617921
(1)   NAS-IP-Address = 192.168.9.17
(1)   Message-Authenticator = 0x7be96e3de48df62ec0bc0e2ab8c1039c
(1) session-state: No cached attributes
(1) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(1)   authorize {
(1)     [preprocess] = ok
(1)     [chap] = noop
(1)     [mschap] = noop
(1)     [digest] = noop
(1) suffix: Checking for suffix after "@"  
(1) suffix: No '@' in User-Name = "4C526224E36D", skipping NULL due to config.  
(1)     [suffix] = noop
(1) ntdomain: Checking for prefix before "\"  
(1) ntdomain: No '\' in User-Name = "4C526224E36D", skipping NULL due to config.  
(1)     [ntdomain] = noop
(1) eap: Peer sent EAP Response (code 2) ID 1 length 22
(1) eap: No EAP Start, assuming it's an on-going EAP conversation  
(1)     [eap] = updated
(1) files: users: Matched entry 4C526224E36D at line 168
(1)     [files] = ok
(1)     if ((notfound || noop) && ("%{%{Control:Auth-Type}:-No-Accept}" != "Accept")) {  
(1)     if ((notfound || noop) && ("%{%{Control:Auth-Type}:-No-Accept}" != "Accept"))  -> FALSE  
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(1)     [daily] = noop
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(1)     [weekly] = noop
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(1)     [monthly] = noop
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(1)     [forever] = noop
(1)     if (&request:Calling-Station-Id == &control:Calling-Station-Id) {
(1)     ERROR: Failed retrieving values required to evaluate condition
(1)     [expiration] = noop
(1)     [logintime] = noop
(1) pap: WARNING: Auth-Type already set.  Not setting to PAP
(1)     [pap] = noop
(1)   } # authorize = updated
(1) Found Auth-Type = eap
(1) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(1)   authenticate {
(1) eap: Expiring EAP session with state 0xbdb22fe8bdb32b2c
(1) eap: Finished EAP session with state 0xbdb22fe8bdb32b2c
(1) eap: Previous EAP request found for state 0xbdb22fe8bdb32b2c, released from the list
(1) eap: Peer sent packet with method EAP MD5 (4)
(1) eap: Calling submodule eap_md5 to process data
(1) eap: Sending EAP Success (code 3) ID 1 length 4
(1) eap: Freeing handler
(1)     [eap] = ok
(1)   } # authenticate = ok
(1) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default
(1)   post-auth {
(1)     update {
(1)       No attributes updated for RHS &session-state:
(1)     } # update = noop
(1)     [exec] = noop
(1)     policy remove_reply_message_if_eap {
(1)       if (&reply:EAP-Message && &reply:Reply-Message) {
(1)       if (&reply:EAP-Message && &reply:Reply-Message)  -> FALSE
(1)       else {
(1)         [noop] = noop
(1)       } # else = noop
(1)     } # policy remove_reply_message_if_eap = noop
(1)   } # post-auth = noop
(1) Login OK: [4C526224E36D] (from client EFS-Switch-RZ-01 port 34 cli 4c:52:62:24:e3:6d)
(1) Sent Access-Accept Id 2 from 192.168.9.1:1812 to 192.168.9.17:57330 length 58
(1)   EAP-Message = 0x03010004
(1)   Message-Authenticator = 0x00000000000000000000000000000000
(1)   User-Name = "4C526224E36D"  
(1) Finished request
Waking up in 4.9 seconds.
Member: aqui
aqui Mar 12, 2023 updated at 14:29:41 (UTC)
Goto Top
Es würde allen sehr helfen wenn du den Output in Code Tags setzen würdest!! face-sad
Foren FAQs zu lesen ist hilfreich... (Der Bearbeiten Knopf ist dein Freund)
Das Posten des überflüssigen Accounting Requests macht die Sache noch weiter unübersichtlicher. face-sad

Nur so viel...
Mit Sent Access-Accept Id 2 from 192.168.9.1:1812 to 192.168.9.17:57330 length 58 ist der Port erfolgreich authentisiert worden. Aus Radius und Port Security Sicht ist damit alles OK und der Port dann offen. Warum der Switch dann (scheinbar) nur DHCP Traffic passieren lässt bleibt schleierhaft und ist vermutlich ein Bug in der Firmware. Bei solcher Gruselhardware wohl mehr oder minder normal.
Andere Switches verhalten sich dabei völlig korrekt wie die du z.B. HIER sehen kannst.
Wenn du ganz sicher bist das du keine dynamischen Port Accesslisten per Radius verteilst oder auch sonst keine anderen Accesslisten oder Firewall Regeln involviert sind ist das vermutlich ein Firmware Bug. Um das genau beurteilen zu können müsste man die Port Konfig des Switches kennen zu der du leider keinerlei Angaben machst.
Ggf. auf die aktuellste Firmware updaten was man so oder so ja immer macht.
Member: commodity
commodity Mar 12, 2023 at 12:36:57 (UTC)
Goto Top
... Code Tags ...
jaaahaaa! Man muss sich nicht wundern, wenn das Netzwerk Schwierigkeiten macht, wenn es schon zu viel ist, die drei einfachen Grundregeln eines Forums zur Kenntnis zu nehmen. Lesen und Verstehen ist der Schlüssel zum Glück. Überall in der IT.
Wir hatten hier kürzlich einen Thread vom Kollegen @letstryandfindout. Der konnte/wollte auch nicht lesen. Am Ende hat er vom Provider-Support die Lösung gesagt bekommen. Vier Stunden, nachdem diese im Forum stand... - aber da war der Nickname wenigstens Programm face-wink
Den maßgeblichen Switch und Controller mal neu gestartet? Updatestand aktuell?
Und wenn man sich alles aus der Nase ziehen lässt, wird es auch nicht einfacher.
Ich grübele gern weiter, wenn das entsprechende Feedback da ist. Viel bleibt aber ohnehin nicht:
a) Firewall Konfig-Fehler
b) Unifi-Firmware-Bug
a) ist immerhin deutlich wahrscheinlicher als b) - aber rechnen musst Du mit allem.

Kopf hoch, es ist alles zu schaffen, wenn man ausreichend Lust drauf hat.

Schönen Sonntag in die Runde! face-smile
Viele Grüße, commodity
Member: lordfire112
lordfire112 Mar 12, 2023 at 15:35:48 (UTC)
Goto Top
Die Firmware der Switch ist natürlich auf aktuellem Stand ebenso die Firewall und die anderen Komponenten.

Die Firewall schließe ich eigentlich aus der DHCP befindet sich auf einem Windows Server der im gleichen VLAN ist und selbst den kann ich ja nach Vergabe der IP nicht pingen…

Wenn nur der Zugriff in andere VLANs oder ins Internet nicht funktioniert würde ich auch an die Firewall denken

Aber im gleichen Netz sollte diese keine Rolle spielen.

Ich werde jetzt mal noch ein Neustart aller Komponenten versuchen

Schönen Sonntag
Member: aqui
aqui Mar 12, 2023 updated at 15:57:18 (UTC)
Goto Top
Haben die UBQT Gurken ggf. sowas wie ein Auth Default VLAN was man evtl. vorher definieren muss in das Clients ohne Radius VLAN Info hineingeworfen werden? GGf. ist das dann ein Fehler in der Konfig? Wir kennen ja die Port Konfig nicht.
Das würde dann aber auch dem Fakt widersprechen das der Client ja im zugewiesenen VLAN problemolos mit dem Server per DHCP kommunizieren kann. Andernfalls hätte er keine IP Adresse bekommen.
Logisch macht das Verhalten alles keinen Sinn und sieht wirklich nach einem Bug aus.

Was passiert denn wenn du spaßeshalber dem Client einmal dediziert die VLAN ID 1 über den Radius zuteilst ala:
# Mein LAN Rechner
4C526224E36D    Cleartext-Password := "4C526224E36D"  
                Tunnel-Type = 13,
                Tunnel-Medium-Type = 6,
                Tunnel-Private-Group-Id = 1 
Member: lordfire112
lordfire112 Mar 12, 2023 at 16:12:10 (UTC)
Goto Top
Die haben ein Default VLAN, das steht auf dem VLAN 1.
Ich habe es auch schon versucht, wie aquai geschrieben hat, explizit das VLAN 1 zuzuweisen, ohne Erfolg.

Ich hab gerade mal nachgeschaut, in einem anderen Netz mit der selben Firmware auf den Switchen funktioniert das ganze, nur war hier alles schon vor dem Firmware update der Switche eingerichtet.

In den UBQT Teilen kann man auch einfach nicht wirklich viel einstellen, Radius angeben, Profil anlegen wann welches VLAN benutzt werden soll und das dann an den entsprechenden Port hängen.
Es ist mehr wie seltsam.
Member: aqui
aqui Mar 12, 2023 updated at 16:31:50 (UTC)
Goto Top
Einmal mehr ein Beweis von UBQT besser die Finger zu lassen! face-sad Das können sogar die Chinesen deutlich besser.
Member: lordfire112
Solution lordfire112 Mar 13, 2023 at 16:12:45 (UTC)
Goto Top
Problem gelöst!
Die neue Oberfläche von UQBNT hat einen Bug, ich habe die Einstelleungen über die alte Oberfläche noch einmal überprüft und dabei ist mir aufgefallen, dass nicht alle Einstellungen übernommen werden.
Ich habe jetzt die gesamte VLAN Profile usw. neu unter der alten Oberfläche angelegt und siehe da es funktioniert!
Member: commodity
commodity Mar 13, 2023 at 20:49:06 (UTC)
Goto Top
Jaja,
Zitat von @commodity:
Switche von Ubiquiti
mag ich nicht.
Danke fürs's Feedback!

Viele Grüße, commodity