Probleme mit externem Radius

[weifei]

Hallo zusammen,
ich habe hier ein Problem, dass ohne erkennbaren Grund auf einmal die Authentifizierung über einen externen Radius Server nicht mehr funktioniert.
Zur Fehlersuche habe ich im AP eine Trace auf EAP und RADIUS laufen lassen und Wireshark auf dem WIFI Client und auf dem RADIUS Server mitlaufen lassen. Ablauf: Der Supplicant meldet sich beim AP, der schickt den EAP Request an den Radius und der antwortet mit einer Challenge. Der AP schickt dann einen EAPOL Frame an den Supplicant und der antwortet mit einem Client Hello. Dann bricht die Verbindung ab. Es scheitert also irgendwo beim 4-Way Handshake. Das merkwürdigste daran: teilweise kommen erfolgreiche connects zu stande. Da wir hier aber völlig unterschiedliche Lancom APs und Endgeräte im Einsatz haben, konnte ich die erfolgreichen Verbindungen an keinem bestimmten Faktor festmachen.

Hat jemand eine Idee was hier los ist oder wo ich weiter suchen kann?

Viele Grüße

Bildschirmfoto 2024-11-20 um 12.01.01.png

[Dr.Einstein]

MTU kleiner als 1500 Byte auf der Strecke aber im Lancom stehen noch die 1500 Byte?

[rotwang]

Der Supplicant meldet sich beim AP, der schickt den EAP Request an den Radius

...streng genommen einen EAP Response, eingepackt in einen RADIUS Request. Bei 802.1X bekommt der Client Requests und schickt Responses. Den initialen Request, nämlich den Identity Request, schickt der AP von sich aus, und den Identity Response vom Client leitet er dann an den RADIUS-Server weiter.

und der antwortet mit einer Challenge.

...der üblicherweise ein Start für die vom RADIUS-Server im Default angenommene EAP-Methode enthält. Bei WLAN üblicherweise EAP-TLS, TTLS oder PEAP. Falls der Client die Methode nicht mag, schickt er darauf ein NAK mit einem Gegenangebot...

Der AP schickt dann einen EAPOL Frame an den Supplicant und der antwortet mit einem Client Hello.

...bei Dir ist der Client aber mit der vom RADIUS-Server vorgeschlagenen Methode einverstanden und schickt das erste eigentliche Paket der EAP-Methode. Die drei genannten Methoden bauen alle als erstes einen TLS-Tunnel auf, und das Client Hello ist das erste Paket einer TLS-Verhandlung.

Dann bricht die Verbindung ab.

Das ist eine etwas schwammige Bescheibung dessen, was passiert. Du solltest mindestens sehen, dass der RADIUS-Client im AP dieses Client Hello in Richtung RADIUS-Server weiter leitet, so wie der es auch schon vorher mit dem Identity Response gemacht hat.

Es scheitert also irgendwo beim 4-Way Handshake.

Nein, der kommt viel später, nach erfolgreicher 1X-Authentisierung, wenn das für den 4W-HS erforderliche und daraus abgeleitete PMK auf beiden Seiten vorhanden ist.

Das merkwürdigste daran: teilweise kommen erfolgreiche connects zu stande. Da wir hier aber völlig unterschiedliche Lancom APs und Endgeräte im Einsatz haben, konnte ich die erfolgreichen Verbindungen an keinem bestimmten Faktor festmachen.

Du wirst letzten Endes schauen müssen, ob der Client Hello irgendwo auf dem Weg zum RADIUS-Server versackt, oder die Antwort vom RADIUS-Server darauf, die üblicherweise ein Server Hello/Certificate/Server Key Exchange enthält - oder das erste Fragment davon, EAP-TLS und darauf aufsetzende Methoden unterstützen Fragmentierung.

Ich weiß jetzt nicht, wo Dein RADIUS-Server netzwerkmäßig steht. Wenn der Weg vom AP über weitere Router geht: Die Antwort vom RADIUS-Server an der Stelle ist häufig trotz Fragmentierung im EAP-TLS so gross, dass das letzten Endes daraus entstehende RADIUS-Challenge auf IP-Ebene fragmentiert wird. Falls irgendein Router auf dem Weg so konfiguriert ist, fragmentierte IP-Pakete zu verwerfen, ist an der Stelle Schluss. Dann musst Du suchen, ob Du auf Client oder RADIUS-Server die Möglichkeit hast, an der EAP-MTU zu drehen (das ist eine andere MTU als die vom IP!)

[GrandDixence]

MTU kleiner als 1500 Byte auf der Strecke aber im Lancom stehen noch die 1500 Byte?

EAP-Datenpakete erreichen gerne eine Grösse > 1500 Byte, was zu fragmentierten Datenpakete führt. Wenn in der Firewall kein "Reassemblieren" konfiguriert ist, werden diese fragmentierten Datenpakete von der Firewall verworfen.
viewtopic.php?p=104492&hilit=reassemblieren#p104492

Und wenn ich es richtig im Kopf habe, ist es noch richtig fies: Die ersten EAP-Datenpakete sind in der Regel < 1500 Byte, erst das dritte EAP-Datenpaket ist dann grösser als 1500 Byte. Ähnliches gibt es ja auch beim VPN-Tunnelaufbau zu beobachten (IKEv2).

[weifei]

Hallo zusammen,
erstmal vielen Dank für die Antworten und Infos und sorry wenn ich mich etwas schwammig ausdrücke - ich bin kein Netzwerkspezialist.

Ich habe jetzt ein Trace auf dem AP und Endgerät mitlaufen lassen und sehe, dass das Endgerät ein Client Hello sendet, was der AP nicht an den RADIUS weiterleitet.

Woran könnte das liegen?

Viele Grüße

Bildschirmfoto 2024-11-22 um 09.17.02.png

Bildschirmfoto 2024-11-22 um 09.14.27.png

Update:
Ich habe jetzt auf dem RADIUS das Attribut Framed-MTU 1036 gesetzt und damit läuft die Authentifizierung erfolgreich durch.

[Jupp]

Ein ganz mieses Ding - sowas will man nicht suchen müssen. Danek schon mal die die Vollständigkeit der Lösung. Ich muss in den kommenden Wochen auch LANCOM AP's mit einem Microsoft-NPS verheiraten. Da freue ich mich schon seit Wochen drauf.