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
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: 04.11.2024 um 18:11 Uhr
9 Kommentare
Neuester Kommentar
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...
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...
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.
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?