24.03.2015, aktualisiert am 18.06.2015

3115

FreeRadius-Server (raspberry pi) kann keine neuen Clients in andere VLANs zuordnen

Hallöchen allerseits,

wir haben ein kleines Problem in unserer Abteilung und suchen nach Rat.

wie im Titel beschrieben, verwenden wir einen raspberry pi als Radius-Server, welcher wenn mich nicht alles täuscht direkt an die Firewall gekoppelt ist. Das Konzept hat bis jetzt super funktioniert. Der Radius-Server hatte bisher allen eingesessenen Benutzern das richtige VLAN zugewiesen, ohne größere Probleme zu machen. Allerdings will er dies nicht mehr bei neuen Nutzern machen.

Bisher mussten wir immer nur die MAC samt VLAN in eine Config einfügen, den Service neustarten und voila.. es passte. Jetzt wenn ich das mache, tut sich einfach nichts.

Um welche Geräte es sich handelt:
Der client Windows 8.1 Pro Laptop.
Unsere Firewall ist von Watchguard - Modell XTM. Der Radius-Server ist dort auch hinterlegt.

Der neue Client soll dem VLAN 10 "Management" zugewiesen werden, erhält jedoch immer nur das VLAN 30.
Der Client selber ist in der Lage den Radius zu pingen. umgekehrt ist das allerdings nicht möglich. Dafür kann der Radius alle anderen pingen außer den Client.

In der Firewall haben wir auch Test halber mal für den Radius alle Ports in Trusted rein und raus freigegeben. Hat leider nichts gebracht.

Um zu gucken wo der Radius alles durch kommt, habe ich mal einen Traceroute gemacht. Das Ergebnis war, dass dieser beim ersten Hop an der Firewall hängen bleibt, was für mich nicht erklärlich ist, weil der eben alle Ports frei bekommen hat. Natürlich habe ich die Regeln auch relativ weit oben gesetzt um zu gucken, ob es wirklich daran liegt.

Hat dazu einer eine Idee, oder Vorschläge?

Danke

Grüße

edit: ich hab mal nachgesehen. der radius ist am switch von cisco angeschlossen. kann es eventuell sein, dass dort der cache voll ist?

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

Content-ID: 267249

Url: https://administrator.de/forum/freeradius-server-raspberry-pi-kann-keine-neuen-clients-in-andere-vlans-zuordnen-267249.html

Ausgedruckt am: 27.12.2024 um 10:12 Uhr

21 Kommentare

Neuester Kommentar

Die hiesigen Tutorials zu dem Thema hast du gelesen zu dem Thema??
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Speziell der Punkt zu dyn. VLANs:
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch

Hilfreich in deinem Falle auch sicher noch:
Netzwerk Management Server mit Raspberry Pi

Wenn du all das beachtest sollte es keinerlei Probleme geben ?!

welcher welcher wenn mich nicht alles täuscht direkt an die Firewall gekoppelt

Solche Aussagen wie "wenn mich nicht alles täuscht" sind natürlich tödlich für ein Troubleshooting über ein Forum. WIE bitte sollen wir denn kontrollieren ob das nun stimmt oder nicht ?
Checke das also wasserdicht und poste das Ergebnis hier!

Bisher mussten wir immer nur die MAC samt VLAN in eine Config einfügen, den Service neustarten und voila.. es passte.

So sollte es ja auch sein !

Unsere Firewall ist von Watchguard - Modell XTM. Der Radius-Server ist dort auch hinterlegt.

Das ist Blödsinn, denn die FW hat damit ja gar nichts zu tun ! "Hinterlegen" dort ist also völlig unsinnig. Außer vielleicht das du damit meinst das der Radius Traffic die Firewall passieren darf.
Wenn überhaupt, dann ist die Radius Konfig auf dem LAN Switch oder WLAN AP relevant, niemals aber auf einer Firewall sofern die nicht selber irgendwas gegen den Radius authentisiert.
Das solltest du hier also auch nochmal klarstellen.

Radius benutzt die Ports 1812 (Authentication) und 1813 (Accounting). ACHTUNG hier: Ältere Radius Implementationen benutzen teilweise noch die Ports 1645 und 1646. Stelle also sicher das deine Endgeräte die richtigen Ports verwenden !
Wenn auf deinem RasPi tcpdump installiert ist (apt-get install tcpdump) dann kannst du dort tcpdump port 1812 eingeben, das zeigt dir dann alle eingehenden Radius Pakete an also ob vom Switch oder AP überhaupt Radius Requests der angeschlossenen Winblows 8.1 Clients den Server erreichen!
Das wäre ja logischerweise der erste Schritt wenn man mal strategisch vorgeht !
Kommt dort gar nix an, dann solltest du dringenst mal die Firewall Regeln überprüfen und demjenigen auf die Finger hauen der die administriert.

servus, erstmal danke für die antwort!

das problem ist, dass ich das netz samt vlans nicht aufgesetzt habe und genauso wenig die firewall eingerichtet.

die verbindung vom radius server verläuft erst über den switch von cisco, weiter zur firewall.

und doch die firewall hat damit was zu tun. immerhin ist in dessen "authentication -> servers" der radius server mit dem port 1812 und der ip hinterlegt.

wie gesagt der tut seinen job noch. denn ich habe spaßeshalber mal den mac beim client gefaket.
ein kollege ist derzeit nicht da und da habe ich mal kurzerhand die im radius server hinterlegte mac von dessen rechner kopiert und manuell beim neuen Client eingetragen.
voila ... der neue client erhält das richtige VLAN.

also warum kann der die alten clients verwalten, aber nicht die neuen?

wie ich im 1. post beschrieben habe, habe ich ein TRACEROUTE (ähnlich wie bei windows tracert) vom radius server aus gemacht. genau zu der IP des neuen Clients und beim 1. Hop der bei unserer Firewall beginnt und endet. egal ob ich tcp, oder udp pakete auf speziellen ports verwende.

das problem ist, dass ich das netz samt vlans nicht aufgesetzt habe und genauso wenig die firewall eingerichtet.

Das tut ja erstmal fürs Troubleshooting nix zur Sache.

die verbindung vom radius server verläuft erst über den switch von cisco, weiter zur firewall.

Ganz einfach: Kannst du vom Cisco Switch der die VLAN Zuordnung machen soll den Radius Server anpingen ?
Damit überprüfst du ob der Switch den Server erreichen kann.

Noch sinnvoller ist es den FreeRadius auf dem RasPi mal mit der Degugging Option "-X" also freeradius -X zu starten und dann mal einen 802.1x Client sich anmelden zu lassen.
Dann kannst du am FreeRadius sofort den eigehenden Request sehen und sofort sehen was der Radius damit macht und obs Fehler gibt.
Das ist in 3 Minuten erledigt und gibt dir dann Gewissheit ob
a.) Der Switch Kontakt zum Radius hat und die FW nix blockt
b.) Der Radius Request sauber und korrekt abgearbeitet wird.
Diese Info oder der Output wäre hier sehr sehr hilfreich !

und doch die firewall hat damit was zu tun.

OK, dann macht die FW die Admin User Authentisierung auch über den Radius, was ja aus Sicherheitssicht vorbildlich ist

voila ... der neue client erhält das richtige VLAN.

OK, das zeigt generell erstmal das an deiner Infrastruktur und Radius vermutlich nichts falsch ist ! Vermutlich...

also warum kann der die alten clients verwalten, aber nicht die neuen?

Da ist dann ganz klar irgendwas faul mit den alten 802.1x Clients.
Wie gesagt, setz den Freeradius und den Debug Mode und mach so einen Connect Zugriff mit einem alten Client und seh dir das an. Da siehst du in Sekundenschnelle wo es kneift.

habe ich ein TRACEROUTE (ähnlich wie bei windows tracert) vom radius server aus gemacht. genau zu der IP des neuen Clients und beim 1. Hop der bei unserer Firewall beginnt und endet.

Das ist Blödsinn, denn wenn der Client NICHT authentisiert ist mit 802.1x kommt dieser Traceroute niemals an !
Logisch ! Denn der Port an dem dieser Client ist ist ja dicht solange der nicht authentisiert ist.
Folglich MUSS das also logischerweise scheitern !
Anders sieht die Sache aus wenn der authentisiert ist. Dann ist es die Firewall !!
Die blockt dann ICMP Traffic. Traceroute nutzt wie Ping ICMP Pakete und das ist in der Firewall dann zu 99% geblockt in den regeln.
Check das !
Also deine To Dos um das rauszubekommen:

FreeRadius im Debug und eingehende Requests checken
Firewall Regeln überprüfen und ins Log sehen was da geblockt wird.

P.S.: Deine Shift Taste auf der Tastatur ist defekt. Solltest du mal reparieren !

das ist ein ausschnitt von einem anderen aber auch neuem client. die anfrage kommt zwar an, erhält aber dennoch kein anderes vlan.

der erste soll den neuen client darstellen. der 2. user muss ein anderer sein, der sich rein zufällig eingeloggt hat.

Ready to process requests.
rad_recv: Access-Request packet from host 192.168.1.30 port 49205, id=0, length=118
NAS-IP-Address = 192.168.1.30
NAS-Port-Type = Ethernet
NAS-Port = 63
User-Name = "00c0eeb7c477"
Acct-Session-Id = "050009DC"
Calling-Station-Id = "00-C0-EE-B7-C4-77"
EAP-Message = 0x0200001101303063306565623763343737
Message-Authenticator = 0x558bae9af47f5d467f905772d511c3c6

Executing section authorize from file /etc/freeradius/sites-enabled/default

+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "00c0eeb7c477", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 0 length 17
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry 00c0eeb7c477 at line 365
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING: Auth-Type already set. Not setting to PAP
++[pap] returns noop
Found Auth-Type = EAP

Executing group from file /etc/freeradius/sites-enabled/default

+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type md5
rlm_eap_md5: Issuing Challenge
++[eap] returns handled
Sending Access-Challenge of id 0 to 192.168.1.30 port 49205
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "100"
EAP-Message = 0x0101001604108e62a9c6387ffa2e1a82d4c182f2c54e
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x3a9b13c23a9a172feb782da0ab588202
Finished request 2.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 192.168.1.30 port 49205, id=0, length=153
Cleaning up request 2 ID 0 with timestamp +472
NAS-IP-Address = 192.168.1.30
NAS-Port-Type = Ethernet
NAS-Port = 63
User-Name = "00c0eeb7c477"
Acct-Session-Id = "050009DC"
State = 0x3a9b13c23a9a172feb782da0ab588202
Calling-Station-Id = "00-C0-EE-B7-C4-77"
EAP-Message = 0x0201002204101d5f878d78d720bf12b2ac7d1b5d7824303063306565623763343737
Message-Authenticator = 0x6e6baa2b1a242c9d7737a0c802fe4cb9

Executing section authorize from file /etc/freeradius/sites-enabled/default

+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "00c0eeb7c477", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 1 length 34
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry 00c0eeb7c477 at line 365
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING: Auth-Type already set. Not setting to PAP
++[pap] returns noop
Found Auth-Type = EAP

Executing group from file /etc/freeradius/sites-enabled/default

+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/md5
[eap] processing type md5
[eap] Freeing handler
++[eap] returns ok

Executing section post-auth from file /etc/freeradius/sites-enabled/default

+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 0 to 192.168.1.30 port 49205
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "100"
EAP-Message = 0x03010004
Message-Authenticator = 0x00000000000000000000000000000000
User-Name = "00c0eeb7c477"
Finished request 3.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 3 ID 0 with timestamp +472
Ready to process requests.

zum vergleich hat sich zufällig ein anderer bekannter user für den radius authentifiziert

Ready to process requests.
rad_recv: Accounting-Request packet from host 192.168.1.30 port 49205, id=0, length=124
User-Name = "28cfe94d5509"
NAS-IP-Address = 192.168.1.30
NAS-Port = 55
Called-Station-Id = "5C-A4-8A-73-21-2B"
Calling-Station-Id = "28-CF-E9-4D-55-09"
Acct-Status-Type = Stop
Acct-Session-Id = "050009E2"
Acct-Authentic = RADIUS
Acct-Session-Time = 2898
Acct-Terminate-Cause = Admin-Reset
NAS-Port-Type = Ethernet

Executing section preacct from file /etc/freeradius/sites-enabled/default

+- entering group preacct {...}
++[preprocess] returns ok
[acct_unique] Hashing 'NAS-Port = 55,Client-IP-Address = 192.168.1.30,NAS-IP-Address = 192.168.1.30,Acct-Session-Id = "050009E2",User-Name = "28cfe94d5509"'
[acct_unique] Acct-Unique-Session-ID = "7a564352d0c5e697".
++[acct_unique] returns ok
[suffix] No '@' in User-Name = "28cfe94d5509", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
++[files] returns noop

Executing section accounting from file /etc/freeradius/sites-enabled/default

+- entering group accounting {...}
[detail] expand: %{Packet-Src-IP-Address} -> 192.168.1.30
[detail] expand: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d -> /var/log/freeradius/radacct/192.168.1.30/detail-20150326
[detail] /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.1.30/detail-20150326
[detail] expand: %t -> Thu Mar 26 14:53:53 2015
++[detail] returns ok
++[unix] returns ok
[radutmp] expand: /var/log/freeradius/radutmp -> /var/log/freeradius/radutmp
[radutmp] expand: %{User-Name} -> 28cfe94d5509
++[radutmp] returns ok
++[exec] returns noop
[attr_filter.accounting_response] expand: %{User-Name} -> 28cfe94d5509
attr_filter: Matched entry DEFAULT at line 12
++[attr_filter.accounting_response] returns updated
Sending Accounting-Response of id 0 to 192.168.1.30 port 49205
Finished request 3.
Cleaning up request 3 ID 0 with timestamp +1665
Going to the next request
Ready to process requests.
rad_recv: Accounting-Request packet from host 192.168.1.30 port 49205, id=0, length=124
User-Name = "a820665a60f0"
NAS-IP-Address = 192.168.1.30
NAS-Port = 65
Called-Station-Id = "5C-A4-8A-73-21-35"
Calling-Station-Id = "A8-20-66-5A-60-F0"
Acct-Status-Type = Stop
Acct-Session-Id = "050009E4"
Acct-Authentic = Local
Acct-Session-Time = 1794
Acct-Terminate-Cause = Admin-Reset
NAS-Port-Type = Ethernet

Executing section preacct from file /etc/freeradius/sites-enabled/default

+- entering group preacct {...}
++[preprocess] returns ok
[acct_unique] Hashing 'NAS-Port = 65,Client-IP-Address = 192.168.1.30,NAS-IP-Address = 192.168.1.30,Acct-Session-Id = "050009E4",User-Name = "a820665a60f0"'
[acct_unique] Acct-Unique-Session-ID = "c514dcc284d953d2".
++[acct_unique] returns ok
[suffix] No '@' in User-Name = "a820665a60f0", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
++[files] returns noop

Executing section accounting from file /etc/freeradius/sites-enabled/default

+- entering group accounting {...}
[detail] expand: %{Packet-Src-IP-Address} -> 192.168.1.30
[detail] expand: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d -> /var/log/freeradius/radacct/192.168.1.30/detail-20150326
[detail] /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.1.30/detail-20150326
[detail] expand: %t -> Thu Mar 26 14:55:33 2015
++[detail] returns ok
++[unix] returns ok
[radutmp] expand: /var/log/freeradius/radutmp -> /var/log/freeradius/radutmp
[radutmp] expand: %{User-Name} -> a820665a60f0
++[radutmp] returns ok
++[exec] returns noop
[attr_filter.accounting_response] expand: %{User-Name} -> a820665a60f0
attr_filter: Matched entry DEFAULT at line 12
++[attr_filter.accounting_response] returns updated
Sending Accounting-Response of id 0 to 192.168.1.30 port 49205
Finished request 4.
Cleaning up request 4 ID 0 with timestamp +1765
Going to the next request
Ready to process requests.

Kann das sein das du EAP statt PEAP bei diesen Clients aktiviert hast ?
Die die nicht funktionieren nutzen auf alle Fälle ein anderes Protokoll. So wie es aussieht ist das Problem ein reines Clietn problem, das dort das Authentisierungs Protokoll unterschiedlich gesetzt ist.
Check das mal.

Ich persönlich hatte weder den Radius, noch das Netzwerk eingerichtet. ^^ Ich soll nur eine Lösung finden.
Aber wenn es am Protokoll liegt, frage ich mich warum es funktioniert, wenn ich dem Ethernet am Client eine andere MAC vorgaukel? Ich hatte ja als Test dem Client die MAC vom Chef zugewiesen und es läuft.

Ich persönlich hatte weder den Radius, noch das Netzwerk eingerichtet. ^^ Ich soll nur eine Lösung finden.

Haben wir ja verstanden aber das hilft dir nicht bei der Fehlersuche....

frage ich mich warum es funktioniert, wenn ich dem Ethernet am Client eine andere MAC vorgaukel?

Mmmhhh, du meinst damit das du einem Client bei dem es normal NICHT funktioniert eine Mac Adresse fakest von einem Client mit dem es funktioniert und dann klappt es mit eben diesem Client ??
Das wäre in der Tat interessant zeigt dann aber ganz klar das es Unterschiede in der Client Konfiguration in der users Datei des FreeRadius gibt.
Anders wäre das ja dann nicht mehr zu erklären wenn das obige wirklich stimmt.
Da wäre es dann hilfreich wenn du mal einen Auszug aus der useres Datei für einen Mac User postest der funktioniert und einer bei dem es nicht klappt.

P.S.: Wieso ist der Thread denn nun auf "gelöst" gesetzt. Ist das Problem gelöst ??

Also auf gelöst gesetzt habe ich es nicht?

Die Users config habe ich mir schon des öfteren angesehen und mir sind keine Fehler in den Eintragungen aufgefallen. Sie sind also so ziemlich identisch, eben bis auf die MAC und das VLAN.

Mir ist aber aufgefallen, dass es die [users] und die [users~] config im Ordner gibt. Beide haben die selben Einträge, also bei users~ habe ich die neuen noch nachträglich eingetragen, um auch das als Fehlerquelle auszuschließen.

Also wie gesagt, es funktioniert einwandfrei, wenn ich auf dem neuen Client direkt eine MAC-Adresse eines anderen Clients in den Ethernet-Adapter eintrage bei dem es funktioniert.

Der funktioniert. und diesen hatte ich auch beim neuen Client eingefügt.

Die XXXe sind nur zensur.

#Hr. XXXXX

"28cfe94d5XXX" Cleartext-Password := "28cfe94d5XXX"
Tunnel-Type = 13,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-Id = 10

Der neue Client

#"NB0040"

"0050B67C8XXX" Cleartext-Password := "0050B67C8XXX"
Tunnel-Type = 13,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-ID = 10

Wenn ich die MAC wieder aus dem Adapter raus nehme und der seine Standard MAC verwendet, kommt es wieder beim Radius zum obigen ersten verfahren.
Er erhält die Anfrage, bearbeitet diese, aber weißt keine Adresse zu.
Was vieeeellleiiicht möglich ist ich aber bezweifel, dass im Adress-Pool des DHCP-Servers ein 24er Subnetz für das VLAN 10 zur Verfügung steht und bekanntlich nur 6 Clients im VLAN 10 sind. Das der DHCP vielleicht keine neue Adresse zuweisen kann?
Allerdings erhält der Client auch keine IP aus dem VLAN 20. Es bleibt immer bei VLAN 100 (192.168.30.0)
Völlig strange das ganze.

Also auf gelöst gesetzt habe ich es nicht?

Sorry, aber das ist Blödsinn, das kannst nur DU selber als TO !
Kann man übrigens mit Klick auf "Bearbeiten" beim Thread auch wieder rückgängig machen.

Das Verhalten ist abartig...das es mit ändern der Mac funktioniert. Kann eigentlich nicht sein... :-o
Fakt ist aber das der Radius die Requests anders behandelt ! Das kannst du sehen wenn du dir die Debugs mal genauer ansiehst.
Das interne Durchlaufen der Auhtnetisierungs Modi ist unterschiedlich.
Damit kann das fast eigentlich nur noch vom Switch selber kommen. Das einzige was übrig bleibt.

Was ist das für ein Switch ? (Hersteller)
Ist die Firmware des Switches auf dem aktuellsten Stand ?

Man müsste sich mal die Radius Auth Messages die der an den Server sendet mit einem Wireshark genau ansehen. Da muss es unterschiede geben.

Zitat von @aqui:

Sorry, aber das ist Blödsinn, das kannst nur DU selber als TO !
Kann man übrigens mit Klick auf "Bearbeiten" beim Thread auch wieder rückgängig machen.

War ja auch keine absicht. Ich habe den button nie bewusst gedrückt ... is jetzt auch geändert.

Das Verhalten ist abartig...das es mit ändern der Mac funktioniert. Kann eigentlich nicht sein... :-o
Fakt ist aber das der Radius die Requests anders behandelt ! Das kannst du sehen wenn du dir die Debugs mal genauer ansiehst.

Die Unterschiede in den Debugs sind mir aufgefallen, ich hab die selber schon fieberhaft verglichen.

Das interne Durchlaufen der Auhtnetisierungs Modi ist unterschiedlich.
Damit kann das fast eigentlich nur noch vom Switch selber kommen. Das einzige was übrig bleibt.

Was ist das für ein Switch ? (Hersteller)

Cisco. Dazu habe ich jedoch noch keine Zugangsdaten erhalten.

* Ist die Firmware des Switches auf dem aktuellsten Stand ?

Muss ich noch überprüfen, sobald ich die Logindaten hab.

Man müsste sich mal die Radius Auth Messages die der an den Server sendet mit einem Wireshark genau ansehen. Da muss es
unterschiede geben.

Wo wär es ratsam eine Maschine mit Wireshark dran zu hängen? Direkt am Switch? Und auf welche Pakete sollte ich besonders achten?
Heute werde ich wahrscheinlich nicht dazu kommen, wenn dann nächste Woche Montag.

Cisco.

WELCHER ?? IOS Catalyst oder SG-xxx Billigserie ?
Lass dir doch nicht alles einzeln aus der Nase ziehen...

Die 802.1x Switchkonfig wäre mal ganz hilfreich. Und der FW Stand.

Wo wär es ratsam eine Maschine mit Wireshark dran zu hängen? Direkt am Switch?

Ja, der Wireshark Sniffer sollte irgendwo im Pfad zwischen Switch und Radius Server sein !
Am besten generierst du einen Mirrorport am Switch und schliesst den Sniffer dort an.

Und auf welche Pakete sollte ich besonders achten?

Setz einen Capture Filter auf und filter auf die Source IP des Switches und Destination IP des Radius Servers.
Dann sniffert der Wireshark nur mit was zwischen Switch und Radius passiert. Den Rest vom Traffic foltert er dann weg.
Zum ansehen für andere (sofern das OK für dich ist) kannst du den Trace auf der Wireshark Seite posten in einem Viewer.

Zitat von @aqui:

> Cisco.
WELCHER ?? IOS Catalyst oder SG-xxx Billigserie ?
Lass dir doch nicht alles einzeln aus der Nase ziehen...

Die 802.1x Switchkonfig wäre mal ganz hilfreich. Und der FW Stand.
> Wo wär es ratsam eine Maschine mit Wireshark dran zu hängen? Direkt am Switch?
Ja, der Wireshark Sniffer sollte irgendwo im Pfad zwischen Switch und Radius Server sein !
Am besten generierst du einen Mirrorport am Switch und schliesst den Sniffer dort an.
> Und auf welche Pakete sollte ich besonders achten?
Setz einen Capture Filter auf und filter auf die Source IP des Switches und Destination IP des Radius Servers.
Dann sniffert der Wireshark nur mit was zwischen Switch und Radius passiert. Den Rest vom Traffic foltert er dann weg.
Zum ansehen für andere (sofern das OK für dich ist) kannst du den Trace auf der Wireshark Seite posten in einem Viewer.

Mach ich noch, sind nur derzeit im Stress, weil jetzt jeder sein Büro umgebaut haben will und wir die Leitungen verlegen müssen, deswegen komme ich gerade zu nix.

Na dann warten wir mal gespannt

AAAlssoooo ... ich kam nicht mehr dazu und ich werde auch nicht mehr dazu kommen ... da man die büros und eine ikea küche wichtiger empfand, als ein funktionierendes VLAN. Und nun werde ich nicht mehr dazu kommen mir den Switch anzusehen.
Ich bin den kompletten April nicht mehr in der Firma. Was so viel heißt wie, das Problem darf wer anders lösen, oder sie lassen es so wie es ist bis Mai.

So viel dazu... in diesem Sinne kann man diesen Thread also als "fast Gelöst" ansehen.

Wahrscheinlich liegt es am Switch ... wenn nicht ... Dann entweder an der Firewall, oder am Radius.. Ich hätte es gerne herausgefunden. :/

Trotzdem vielen dank für deine Hilfe!

ich kam nicht mehr dazu und ich werde auch nicht mehr dazu kommen ...

Schade eigentlich...

da man die büros und eine ikea küche wichtiger empfand, als ein funktionierendes VLAN.

Igitt...Ikea ! Na ja man muss halt Prioritäten setzen was wichtig ist und was nicht...

Ich bin den kompletten April nicht mehr in der Firma. Was so viel heißt wie, das Problem darf wer anders lösen

Du musst dich hier nicht rechtfertigen und dein Berufsleben offenlegen. Besser du behälst das für dich !

kann man diesen Thread also als "fast Gelöst" ansehen.

Dann erlöse uns bitte und vergesse
Wie kann ich einen Beitrag als gelöst markieren?
nicht dafür !

Tja dann gibt es keine lösung für das derzeitige problem.

Eventuelle ursache ist der switch.

Doch die Lösung wäre ein Bugfixing der Switch Firmware

wir haben es nach anschaffung einer neuen firewall herausgefunden wo das problem lag.

das problem war die formatierung der MAC-Adresse.

der switch hat nur ein bestimmtes format angenommen.

also anstatt alles in kleinschreibung musste alles großgeschrieben werden.

Genau DAS Problem hast du auch mit deiner Tastatur !
Deine Shift Taste ist defekt. Solltest du mal beizeiten reparieren....

Aber gut wenn nun alles rennt wie es soll !