5
RADIUS Problem
In einem Netzwerk mit Linksys WRT54G als RADIUS-Clients und w2k3 als Server funktioniert die Authentifizierung manchmal nicht.
Hallo,
Es geht um ein WLAN Netzwerk in meiner Schule. Es wird über die WRTS WLAN Zugänge für die Schüler zur Verfügung gestellt. Die Authentifizierung läuft über IAS auf dem Server(mit Server 2k3)
es gibt mehrere Subnets und etwa 15 APs. Die APs sind auf die verschiedenen Subnets verteilt.
Als Zentraler Punkt im Netzerk gibt es einen Summit 48, der mehrere VLANs bereitstellt. Die WRTS sind so konfiguriert, das die RADIUS Pakete ihr Ziel (den Server) erreichen können, auch wenn sie in einem anderen Subnet sind.
Ein AP macht besondere Probleme: Er steht im Nebengebäude und ist über eine "Kette von Geräten" angeschlossen:
Server--Switch(Summit)--Switch(Procurve)---Glasfaser---Switch(Procurve)---AP
So nun finden die Schüler zwar das Netzwerk(also funktioniert der SSID Broadcast) Aber dann meldet Windows (je nach Version) "Konnte keine Verbing herstellen (oder so ähnlich).
Daraus schleiße ich, das der IAS überhaupt keine Anfrage erhält, das deckt sich auch mit den Logs des IAS, in denen für die betreffende Uhrzeit kein Eintrag zu finden ist.
Wir haben mal aus Testgründen vor den ersten Procurve einen Hub gepackt und die Packete mittels Wireshark aufgezeichnet. Das ganze ergab nichts besonderes, aber wir konnten einen großen Traffic an SNMP Paketen eines Druckers erkennen. Kann das den restlichen Verkehr beeinflussen?
Was könnte sonst noch die Ursache sein?
Danke und mfg
Marvin
Hallo,
Es geht um ein WLAN Netzwerk in meiner Schule. Es wird über die WRTS WLAN Zugänge für die Schüler zur Verfügung gestellt. Die Authentifizierung läuft über IAS auf dem Server(mit Server 2k3)
es gibt mehrere Subnets und etwa 15 APs. Die APs sind auf die verschiedenen Subnets verteilt.
Als Zentraler Punkt im Netzerk gibt es einen Summit 48, der mehrere VLANs bereitstellt. Die WRTS sind so konfiguriert, das die RADIUS Pakete ihr Ziel (den Server) erreichen können, auch wenn sie in einem anderen Subnet sind.
Ein AP macht besondere Probleme: Er steht im Nebengebäude und ist über eine "Kette von Geräten" angeschlossen:
Server--Switch(Summit)--Switch(Procurve)---Glasfaser---Switch(Procurve)---AP
So nun finden die Schüler zwar das Netzwerk(also funktioniert der SSID Broadcast) Aber dann meldet Windows (je nach Version) "Konnte keine Verbing herstellen (oder so ähnlich).
Daraus schleiße ich, das der IAS überhaupt keine Anfrage erhält, das deckt sich auch mit den Logs des IAS, in denen für die betreffende Uhrzeit kein Eintrag zu finden ist.
Wir haben mal aus Testgründen vor den ersten Procurve einen Hub gepackt und die Packete mittels Wireshark aufgezeichnet. Das ganze ergab nichts besonderes, aber wir konnten einen großen Traffic an SNMP Paketen eines Druckers erkennen. Kann das den restlichen Verkehr beeinflussen?
Was könnte sonst noch die Ursache sein?
Danke und mfg
Marvin
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 161565
Url: https://administrator.de/contentid/161565
Ausgedruckt am: 22.11.2024 um 21:11 Uhr
5 Kommentare
Neuester Kommentar
Nein, niemals wenn der Druckertraffic nicht 98% der gesamten Bandbreite hat. Trotzdem ist aber auch solch permanenter SNMP Traffic nicht normal, das ist aber eine andere Baustelle die gesondert zu untersuchen ist.
Es gibt 2 mögliche Ursachen für das Radius Problem:
Allerdings hättest du ja wenigstens mit dem Wireshark Trace immer einen Radius Request sehen müssen wenn du direkt am AP mit einem HUB oder Mirrorport am Switch mitsnifferst.
Wenn der Sniffertrace gar keinen Radius Request zeigt dann hast du natürlich erstmal ein generelles Radius Config Problem am AP !!
Den Radius Request des APs solltest du mit einem Sniffer Trace in jedem Falle sehen, egal ob das Routeing oder der TCP Port falsch ist ! Kommt der generell nicht, hast du ein AP Config Problem !
Dazu musst du natürlich sicherstellen das du wirklich ein HUB hast dazwischen und nicht einen sog. Dual Speed Hub der dann auch wieder ein Switch ist und dir den Traffic des APs blockiert.
Am sichersten ist hier immer ein sog. Mirrorport am Switch wo du den AP Port einfach mirrorst. Das sollte sogar Billigheimer HP können sofern deine ProCurve Gurken überhaupt managebar sind. Wenn sie das nicht sind, dann wirds eh nix, dann musst du einen HUB nehmen oder sowas.
Da du aber SNMP Traffic siehst (sofern er kein Broad- oder Multicast ist) funktioniert dein HUB als nur HUB vermutlich !
Es gibt 2 mögliche Ursachen für das Radius Problem:
- Das Routing zw. Radius Server und AP stimmt nicht. Dazu gäbe es aber einen simplen Test indem du einfach vom Radius Server mal die IP Adresse des APs anpingst. Sollte das klappen ist alles OK. Wenns nicht klappt, dann hast du eine Routing Problem ! Hier hilft dann wie immer Traceroute oder Pathping um den Fehler schnell zu finden.
- Sollte ein Ping funktionieren gibt es 2 weitere mögliche Fehler: 1.) die lokale Firewall am Server die ggf. Zugriffe aus diesem AP Subnetz blockiert. 2.) Das der Radius Supplicant im AP einen falschen TCP Port benutzt. Radius hat früher andere Ports als aktuell nämlich 1645 neuer und aktueller ist 1812.
Allerdings hättest du ja wenigstens mit dem Wireshark Trace immer einen Radius Request sehen müssen wenn du direkt am AP mit einem HUB oder Mirrorport am Switch mitsnifferst.
Wenn der Sniffertrace gar keinen Radius Request zeigt dann hast du natürlich erstmal ein generelles Radius Config Problem am AP !!
Den Radius Request des APs solltest du mit einem Sniffer Trace in jedem Falle sehen, egal ob das Routeing oder der TCP Port falsch ist ! Kommt der generell nicht, hast du ein AP Config Problem !
Dazu musst du natürlich sicherstellen das du wirklich ein HUB hast dazwischen und nicht einen sog. Dual Speed Hub der dann auch wieder ein Switch ist und dir den Traffic des APs blockiert.
Am sichersten ist hier immer ein sog. Mirrorport am Switch wo du den AP Port einfach mirrorst. Das sollte sogar Billigheimer HP können sofern deine ProCurve Gurken überhaupt managebar sind. Wenn sie das nicht sind, dann wirds eh nix, dann musst du einen HUB nehmen oder sowas.
Da du aber SNMP Traffic siehst (sofern er kein Broad- oder Multicast ist) funktioniert dein HUB als nur HUB vermutlich !
okay, ich werde dann mal versuchen statt des HUBs ein Port des Summits, oder eines Procurves als Mirror Port zu benutzen und dort den Verkehr mitsniffen.
Was mich ja wundert: ein generelles Probelm scheint ja nicht zu bestehen, denn es funktioniert ja, aber leider nicht immer, wenn es mal nicht funktioniert, dann reicht ein Neustart des APs und alles funktioniert wieder ein paar Tage ohne Probleme.
Ich halte immer noch die vielen SNMP Pakete für eine mögliche Fehlerursache. Alleine der Netzerkstrange von EINEM AP zum Server produzierte innerhalb 2 Tagen 28.000 SNMP pakete.
Kann das sein, das in der zeit einfach nicht genug bandbreite für den RADIUS-Verkehr zur verfügung steht?
Gruß
Marvin
Was mich ja wundert: ein generelles Probelm scheint ja nicht zu bestehen, denn es funktioniert ja, aber leider nicht immer, wenn es mal nicht funktioniert, dann reicht ein Neustart des APs und alles funktioniert wieder ein paar Tage ohne Probleme.
Ich halte immer noch die vielen SNMP Pakete für eine mögliche Fehlerursache. Alleine der Netzerkstrange von EINEM AP zum Server produzierte innerhalb 2 Tagen 28.000 SNMP pakete.
Kann das sein, das in der zeit einfach nicht genug bandbreite für den RADIUS-Verkehr zur verfügung steht?
Gruß
Marvin
Nein, die Radius Anfragen sind nur ganz vereinzelnde und zudem kleine Pakete und du müsstest dann schon ziemlich miese Netzwerk Infrastruktur haben oder eine Riesenlast auf dem Port über 80% damit sowas auf der Strecke bleibt.
Wenn du aber den AP mal mit einem -t und -l 512 vom Server anpingst über einen längeren Zeitraum und keiner der Pings geht verloren dann liegt es de facto nicht am Netz und der SNMP Belastung.
Außerdem kannst du ja auch an der ProCurve Gurke (solange sie managebar ist) ganz einfach und banal mal ein show interface eth x eingeben am Uplink Port !
Dort siehst du ja dann die Belastung in Prozent. Wenn das unter 60% ist ist die SNMP Last harmlos und zu vernachlässigen.
Leider lieferst du diese Info ja nicht, so das eine hilfreiche Aussage nicht möglich ist und wir hier nur weiter raten können : - (
Bedenklich ist das allerdings schon mit dem SNMP da nicht normal. Du solltest also den Sniffer mal nehmen und checken von wo nach wo diese SNMPs gehen bzw. WO der Drucker diese hinsendet.
Sinnvoll ist auch mit dem Wireshark mal nachzusehen im SNMP Datenfeld WAS da genau gemacht wird (get, set oder traps)
Das Gerät was diese SNMP empfängt, was auch immer das sein mag, (du aber an dessen Ziel IP Adresse einwandfrei und schnell identifizieren kannst !!) hat mit an Sicherheit grenzender Wahrscheinlichkeit eine Fehlkonfiguration. Ein Beseitigen dieser Ursache ist also sicher nicht verkehrt auf Dauer gesehen....
Wenn du aber den AP mal mit einem -t und -l 512 vom Server anpingst über einen längeren Zeitraum und keiner der Pings geht verloren dann liegt es de facto nicht am Netz und der SNMP Belastung.
Außerdem kannst du ja auch an der ProCurve Gurke (solange sie managebar ist) ganz einfach und banal mal ein show interface eth x eingeben am Uplink Port !
Dort siehst du ja dann die Belastung in Prozent. Wenn das unter 60% ist ist die SNMP Last harmlos und zu vernachlässigen.
Leider lieferst du diese Info ja nicht, so das eine hilfreiche Aussage nicht möglich ist und wir hier nur weiter raten können : - (
Bedenklich ist das allerdings schon mit dem SNMP da nicht normal. Du solltest also den Sniffer mal nehmen und checken von wo nach wo diese SNMPs gehen bzw. WO der Drucker diese hinsendet.
Sinnvoll ist auch mit dem Wireshark mal nachzusehen im SNMP Datenfeld WAS da genau gemacht wird (get, set oder traps)
Das Gerät was diese SNMP empfängt, was auch immer das sein mag, (du aber an dessen Ziel IP Adresse einwandfrei und schnell identifizieren kannst !!) hat mit an Sicherheit grenzender Wahrscheinlichkeit eine Fehlkonfiguration. Ein Beseitigen dieser Ursache ist also sicher nicht verkehrt auf Dauer gesehen....
Ich bin leider im Moment nicht an der Schule, deshalb kann ich deine Tipps erst am Monatg morgen umsetzen.
Was ich leider nicht sehe, sind "vereinzelte Pakete" es kommen neben vereinzelten "RADIUS-Request" und "Accept" zahlreiche "RADIUS-Challange" vor und das wirklich häufig. ich habe mir mal das Protokoll bei wiki-en angeschaut und irgendwie kann ich nicht verstehen, was da ständig zwischen Laptops und dem IAS hin- und her gesendet wird.
Ich werde Montag mal die Netzauslastung prüfen.
Ich habe einen Sniffer die SNMP Pakete mitsniffen lassen und das Ergebnis ist seltsam: Ich habe mir jeweils die Source und Destination MACs angeschaut. Nach diesen MACs laufen die Pakete zu dem Linksys AP und dann wieder zum Procurve und Summit zurück und dann erst vom Summit zum Drucker und wieder zurück zum Server. das lustige ist jetzt, dass der Drucker nahezu direkt an dem Summit hängt. Er sollte mit den beiden Procurves und dem AccessPoint nichts zu tun haben.
(Der Drucker hängt aber im gleichen VLAN wie der AP)
Ich wüsste jetzt auch nicht, das SNMP broadcast macht, das ergäbe auch keinen Sinn.
Bei Gelegenheit filtere ich mal die Logs und poste die relevanten Auszüge hier.
Was ich leider nicht sehe, sind "vereinzelte Pakete" es kommen neben vereinzelten "RADIUS-Request" und "Accept" zahlreiche "RADIUS-Challange" vor und das wirklich häufig. ich habe mir mal das Protokoll bei wiki-en angeschaut und irgendwie kann ich nicht verstehen, was da ständig zwischen Laptops und dem IAS hin- und her gesendet wird.
Ich werde Montag mal die Netzauslastung prüfen.
Ich habe einen Sniffer die SNMP Pakete mitsniffen lassen und das Ergebnis ist seltsam: Ich habe mir jeweils die Source und Destination MACs angeschaut. Nach diesen MACs laufen die Pakete zu dem Linksys AP und dann wieder zum Procurve und Summit zurück und dann erst vom Summit zum Drucker und wieder zurück zum Server. das lustige ist jetzt, dass der Drucker nahezu direkt an dem Summit hängt. Er sollte mit den beiden Procurves und dem AccessPoint nichts zu tun haben.
(Der Drucker hängt aber im gleichen VLAN wie der AP)
Ich wüsste jetzt auch nicht, das SNMP broadcast macht, das ergäbe auch keinen Sinn.
Bei Gelegenheit filtere ich mal die Logs und poste die relevanten Auszüge hier.
Oha...das sieht aber dann verdächtig nach einem Routing Loop aus oder Probleme mit dem Routing. Vermutlich hat also eins dieser Komponenten eine falsches Gateway eingetragen.
Sich die Mac Adressen anzusehen ist auch recht unproduktiv...die sagen wenig über die Wegewahl. Da SNMP immer IP basierend ist sind die IP Adressen viel sinnvoller.
Wenn der AP gar kein SNMP macht ist es höchst verwunderlich das dieser auch SNMP Pakete sendet...eigentlich völlig unmöglich.
Ebenso das der Procurve involviert ist ist eigentlich unsinnig, denn das zentrale Routing zw. deinen Subnetzs findet ja auf den Summits statt wenn man dich richtig versteht oben...
Richtig ist auch das SNMP niemals broadcastet, das war oben vermutlich etwas missverständlich ausgedrückt.
Das ist also recht verwirrend bei dir. Ohne aber deine Layer 3 Struktur genauer zu kennen ist eine sinnvolle Hilfe nicht möglich oder endet wie so immer hier in Spekuliererei oder Raterei.
Fazit ist das da aber was mit deinem SNMP Konzept bzw. den beteiligten SNMP Clients ziemlich faul ist und dringend der Aufklärung bedarf !
Was das Radius Thema anbetrifft sendet eigentlich nicht der Laptop sondern der AP selber immer einen Radius Request !! Deshalb wird auch hier der Radius Server definiert und nirgendwo anders. Der AP selber ist der .1x Authenticator nicht der assoziierte Laptop ! Dieser ist nur Supplicant und kennt den Radius bzw. dessen IP gar nicht ! !
http://de.wikipedia.org/w/index.php?title=Datei:8021X-Overview.svg& ...
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Kann also auch irgendwie nicht sein das der Laptop selber mit dem Radius redet.... da hast du also vermutlich was falsches gesniffert...
Sich die Mac Adressen anzusehen ist auch recht unproduktiv...die sagen wenig über die Wegewahl. Da SNMP immer IP basierend ist sind die IP Adressen viel sinnvoller.
Wenn der AP gar kein SNMP macht ist es höchst verwunderlich das dieser auch SNMP Pakete sendet...eigentlich völlig unmöglich.
Ebenso das der Procurve involviert ist ist eigentlich unsinnig, denn das zentrale Routing zw. deinen Subnetzs findet ja auf den Summits statt wenn man dich richtig versteht oben...
Richtig ist auch das SNMP niemals broadcastet, das war oben vermutlich etwas missverständlich ausgedrückt.
Das ist also recht verwirrend bei dir. Ohne aber deine Layer 3 Struktur genauer zu kennen ist eine sinnvolle Hilfe nicht möglich oder endet wie so immer hier in Spekuliererei oder Raterei.
Fazit ist das da aber was mit deinem SNMP Konzept bzw. den beteiligten SNMP Clients ziemlich faul ist und dringend der Aufklärung bedarf !
Was das Radius Thema anbetrifft sendet eigentlich nicht der Laptop sondern der AP selber immer einen Radius Request !! Deshalb wird auch hier der Radius Server definiert und nirgendwo anders. Der AP selber ist der .1x Authenticator nicht der assoziierte Laptop ! Dieser ist nur Supplicant und kennt den Radius bzw. dessen IP gar nicht ! !
http://de.wikipedia.org/w/index.php?title=Datei:8021X-Overview.svg& ...
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Kann also auch irgendwie nicht sein das der Laptop selber mit dem Radius redet.... da hast du also vermutlich was falsches gesniffert...
