EAP TLS WLAN - Verbindungsprobleme an einem Standort

Hallo zusammen,

ich habe ein Problem bei einem EAP-TLS WLAN, welches wir am Hauptstandort und an zwei Zweigstellen ausstrahlen.
Am Hauptstandort und an einer Niederlassung funktioniert die Anmeldung. Am zweiten Standort nicht.
Im Einsatz ist der NPS von MS auf einem Server 2016, eine Sophos XGS (wo die SSID eingerichtet ist) dient als Radius Client, die beiden Zweigstellen haben eine Sophos RED-Box und Sophos Accesspoints sind im Einsatz.

für die zwei Zweigstellen gelten die gleichen Firewall-Rules. Die RED´s sind ebenfalls gleich eingerichtet und auch die gleichen Modelle.
im IAS Log sieht an sich alles normal aus, nur, dass die Clients keine Adresse bekommen aus dem dafür vorgesehenen DHCP Bereich. Daher ist der Connect Result (Unknown).
Das Clientzertifikat passt.
In der XGS im Logviewer steht auch nichts aussagekräftiges. Keine Fehler oder sonstiges.
Ich habe auch schon mal Wireshark mitlaufen lassen, einmal bei einem erfolgreichen Connect von Niederlassung A und einem erfolglosen Connect von Niederlassung B am NPS Server.
Hier sehe ich ebenfalls keine Paket-Drops oder Ähnliches wenn man beides miteinander vergleicht.

Was ich bis jetzt bei Niederlassung B versucht habe:

- MTU anzupassen (obwohl NL A und NL B gleich eingerichtet waren)
- Eine LTE Box als Internet-Gateway (um den sich dort befindlichen Kabel-Anschluss auszuschließen und den dementsprechenden Router) getestet
- Switch vor Ort (an dem Router, AP etc. hängt) testweise getauscht.
- RED neugestartet

Was ich noch machen möchte:

- Die RED Verbindung löschen und neu einrichten und die RED-Box vor Ort tauschen (sobald wir eine neue Box für eine weitere Zweigstelle erhalten)

Danke schon mal im Voraus für die Hilfe.

Viele Grüße
itwahn

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

Content-ID: 53224556523

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

Ausgedruckt am: 21.11.2024 um 22:11 Uhr

9 Kommentare

Neuester Kommentar

Hallo,

wo läuft DHCP Server? An jedem Standort oder getunnelt zum Hauptstandort?

MfG

Nachtrag:
Wenn man dem WLAN-Client eine statische IP gibt, funktionert es dann?

Zitat von @heilgecht:

Hallo,

wo läuft DHCP Server? An jedem Standort oder getunnelt zum Hauptstandort?

MfG

Nachtrag:
Wenn man dem WLAN-Client eine statische IP gibt, funktionert es dann?

Hi, der DHCP Server läuft am Hauptstandort auf der XGS, hatte ich vergessen zu erwähnen sorry.
Das mit der statischen IP habe ich in der Tat noch nicht ausprobiert. Werde ich nächste Woche mal versuchen.

Wenn DHCP in anderem Netz ist, dann brauchst du ja DHCP-Relay oder Multicast-Routing. Oder so wie es bei Lancom ist, kann man dort DHCP-Multicasts in Unicasts umsetzen.

DHCP hat nichts mit Multicast zu tun und basiert bekanntlich rein auf Broadcasts! 🧐
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
Fehlendes DHCP Relay auf der Routing Komponente (FW) zum Hauptstandort dürfte wohl in der Tat das ursächliche Problem sein sofern der zentrale DHCP Server genutzt wird!

Hätte man als Administrator auch kinderleicht mit einem Kupferclient und Wireshark im remoten WLAN Segment selber rausfinden können wenn kein DHCP Reply auf einem DHCP Request des Clients kommt...

Ja natürlich Broadcast, ein Denkfehler von mir. Es ist Freitag.

Mit einer festen IP Adresse aus dem Bereich funktioniert es auch nicht.

Wireshark liefert hier leider für das besagte WLAN nichts, wirklich komischerweise nichts.
Sobald man sich mit einem anderen WLAN verbindet, wird wieder Traffic mitgeschnitten am WLAN Interface.

In der Hauptverwaltung und NL A wird aber sofort Traffic mitgeschnitten für das besagte WLAN am Interface.

Wireshark liefert hier leider für das besagte WLAN nichts, wirklich komischerweise nichts.

Dann scheitert schon die grundlegende Assoziierung / Authentisierung am WLAN an sich, so das es gar nicht erst zur DHCP IP Adressvergabe kommt.
Da hast du dann das grundlegende Problem schon VOR dem DHCP!

Gehe immer strategisch vor beim Troubleshooting.
Du solltest zuallererst einen Client per Kupferport in das WLAN Netzwerk Segment stecken um erstmal die WLAN Authentisierungsprozedur zu umgehen. So kannst du wasserdicht überprüfen das der dann wenigstens per DHCP Relay eine IP vom zentralen DHCP Server für das WLAN IP Netz bekommt.
Wenn das der Fall ist kannst du dann schonmal ein DHCP Problem wasserdicht ausschliessen und hast eine mögliche Fehlerquelle weniger.

Dann musst du dich an das WLAN Problem machen.
Sehr wahrscheinlich scheitert hier auch schon grundsätzlich die Radius Authentisierung und der Client kommt erst gar nicht ins WLAN und kann dann folglich auch gar keinen DHCP Request senden.

Du musst also checken ob der WLAN Accesspoint generell den Radius Server erreichen kann.
Wenn der Accesspoint im Setup GUI oder CLI eine Ping Funktion hat, solltest du als Allererstes prüfen ob der den Radius Server pingen also IP-technisch erreichen kann.