18
Rätselhaftes Netzwerkverhalten (IP, ARP )
Hallo Freunde der gepflegten Unterhaltung.
Wir hatten gestern eine seltsames Phänomen, das möchte ich gern zur Diskussion frei geben.
Unsere Umgebung im Groben:
Controllerbasiertes WLAN (LANCOM, 1 WLC und 300 APs) mit rund 700 Teilnehmern auf einer SSID (eigenes VLAN)
Dieses VLAN kommt auf einer pfsense mit aktueller Software an.
Auch LAN Verbindungen im selben Netzwerk sind vorhanden.
PFSense wohnt auf einen dl360, hat ausreichend Rechenleistung und Speicher.
PFSense übernimmt alle infrastrukturdienste wie DHCP, IP, DNS, Router...
Ebenfalls Firewallfunktionen sowie ein Captive Portal ohne Authentifizierung, lediglich die Geschäftsbedingungen müssen akzueptiert werden.
Dann wird über Radius ein Zugang erstellt, der nach 24 Stunden abläuft.
PFsense ist ebenfalls Internet (standard)Gateway.
Soweit funktionierte alles.
Dann hatten wir folgendes Phänomen:
Einige Benutzer beklagten sich, dass sie das Netzwerk nicht mehr nutzen konnten, weder verkabelt noch WiFi.
Haben wir nachvollzogen und stimmte.
Die Clients meldeten sich am Netzwerk an und bekamen die IP Settings.
Dann ging es nicht weiter.
Dienste auf pfsense liefen normal, trotzdem haben wir die neu gestartet.
Auch das half nichts.
Also weiter.
Ping und ARP auslesen.
Dabei fiel uns auf, dass die falsche Mac Adresse antwortete.
Eine kurze Suche bei Heise ergab, dass es sich um ein Apple Gerät handeln könnte.
Weiter Auswertungen (MAC Address Table am Switch und Trace am WLC) verrieten uns, an welche AP das Gerät assoziierte.
Das grenzte den Suchbereich ein.
Meine Gang hat das Gerät gefunden und die Dame gebeten, das WLAN auszuschalten.
War tatsächlich ein MacBook.
Der hat, aus irgendwelchen Gründen, beim Ping auf die IP Adresse des Routers, geantwortet.
Und damit auch sämtliche DNS Anfragen (nicht) beantwortet.
Nach Ausknipsen war alles gut, auch er Router antwortete wieder korrekt.
Nach Anschalten das selbe Fehlerbild.
Konnte mit Abschalten wieder korrigiert werden.
Das zum Fehlerbild.
Auf dem Mac konnten wir nichts feststellen. Weder in den IP Settings noch in irgendwelchen Protokollen.
Eine VPN Software kommt noch zum Einsatz.
Nach einem Telefonat mit dem IT Mann, der die Firma betreut, kam heraus, dass unsere IP Adresskreise sich auch nicht überschneiden.
Der "gegnerische" IT Mann hat das Gerät remote untersucht, ihm fiel nur auf, dass in den IP Settings (via GUI) die MacAdresse kurz verschwindet.
Im betroffenen VLAN wird nicht geroutet, mal abgesehen vom internetzugang.
IM Vlan konnten wir keine Fehler feststellen.
Die Routeradresse wird nicht per DHCP verteilt.
Der Mac Erhält übrigens tatsächlich eine eigene MacAdresse. Diese ist anpingbar und zeigt die selbe Mac Adressse im ARP Cache. Also gibt es dann zu einer Mac 2 Adressen.
Wir haben das Gerät in ein anderes VLAN verfrachtet, anschliessend war Ruhe. Allerdings haben sich die Bedingungen damit verändert, der Fehler konnte in diesem netz nicht reproduziert werden.
Unserem gast war geholfen, allerdings würde ich gern wisssen, was hier schief gelaufen ist...
Vielleicht habt ihr Ideen.
Herzliche Grüße aus Berlin.
Wir hatten gestern eine seltsames Phänomen, das möchte ich gern zur Diskussion frei geben.
Unsere Umgebung im Groben:
Controllerbasiertes WLAN (LANCOM, 1 WLC und 300 APs) mit rund 700 Teilnehmern auf einer SSID (eigenes VLAN)
Dieses VLAN kommt auf einer pfsense mit aktueller Software an.
Auch LAN Verbindungen im selben Netzwerk sind vorhanden.
PFSense wohnt auf einen dl360, hat ausreichend Rechenleistung und Speicher.
PFSense übernimmt alle infrastrukturdienste wie DHCP, IP, DNS, Router...
Ebenfalls Firewallfunktionen sowie ein Captive Portal ohne Authentifizierung, lediglich die Geschäftsbedingungen müssen akzueptiert werden.
Dann wird über Radius ein Zugang erstellt, der nach 24 Stunden abläuft.
PFsense ist ebenfalls Internet (standard)Gateway.
Soweit funktionierte alles.
Dann hatten wir folgendes Phänomen:
Einige Benutzer beklagten sich, dass sie das Netzwerk nicht mehr nutzen konnten, weder verkabelt noch WiFi.
Haben wir nachvollzogen und stimmte.
Die Clients meldeten sich am Netzwerk an und bekamen die IP Settings.
Dann ging es nicht weiter.
Dienste auf pfsense liefen normal, trotzdem haben wir die neu gestartet.
Auch das half nichts.
Also weiter.
Ping und ARP auslesen.
Dabei fiel uns auf, dass die falsche Mac Adresse antwortete.
Eine kurze Suche bei Heise ergab, dass es sich um ein Apple Gerät handeln könnte.
Weiter Auswertungen (MAC Address Table am Switch und Trace am WLC) verrieten uns, an welche AP das Gerät assoziierte.
Das grenzte den Suchbereich ein.
Meine Gang hat das Gerät gefunden und die Dame gebeten, das WLAN auszuschalten.
War tatsächlich ein MacBook.
Der hat, aus irgendwelchen Gründen, beim Ping auf die IP Adresse des Routers, geantwortet.
Und damit auch sämtliche DNS Anfragen (nicht) beantwortet.
Nach Ausknipsen war alles gut, auch er Router antwortete wieder korrekt.
Nach Anschalten das selbe Fehlerbild.
Konnte mit Abschalten wieder korrigiert werden.
Das zum Fehlerbild.
Auf dem Mac konnten wir nichts feststellen. Weder in den IP Settings noch in irgendwelchen Protokollen.
Eine VPN Software kommt noch zum Einsatz.
Nach einem Telefonat mit dem IT Mann, der die Firma betreut, kam heraus, dass unsere IP Adresskreise sich auch nicht überschneiden.
Der "gegnerische" IT Mann hat das Gerät remote untersucht, ihm fiel nur auf, dass in den IP Settings (via GUI) die MacAdresse kurz verschwindet.
Im betroffenen VLAN wird nicht geroutet, mal abgesehen vom internetzugang.
IM Vlan konnten wir keine Fehler feststellen.
Die Routeradresse wird nicht per DHCP verteilt.
Der Mac Erhält übrigens tatsächlich eine eigene MacAdresse. Diese ist anpingbar und zeigt die selbe Mac Adressse im ARP Cache. Also gibt es dann zu einer Mac 2 Adressen.
Wir haben das Gerät in ein anderes VLAN verfrachtet, anschliessend war Ruhe. Allerdings haben sich die Bedingungen damit verändert, der Fehler konnte in diesem netz nicht reproduziert werden.
Unserem gast war geholfen, allerdings würde ich gern wisssen, was hier schief gelaufen ist...
Vielleicht habt ihr Ideen.
Herzliche Grüße aus Berlin.
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: 433690
Url: https://administrator.de/contentid/433690
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
18 Kommentare
Neuester Kommentar
Riecht nach ARP Poisoning bei dem ein Client versucht den Traffic der Clients der eigentlich an den Router gehen sollten auf sich umzuleiten Stichwort MitM-Attack ...
Zitat von @138810:
Riecht nach ARP Poisoning bei dem ein Client versucht den Traffic der Clients der eigentlich an den Router gehen sollten auf sich umzuleiten Stichwort MitM-Attack ...
Riecht nach ARP Poisoning bei dem ein Client versucht den Traffic der Clients der eigentlich an den Router gehen sollten auf sich umzuleiten Stichwort MitM-Attack ...
ARP-Poisoning war auch mein erster Gedanke, allerdings sehr stümperhaft ausgeführt, weil das Netz lahmgelegt wurde.
Ich würde mal schauen, ob der Apfel denn wirklich "sauber" ist. Denn normal ist so ein Verhalten nicht.
lks
Moin,
ich fasse kurz zusammen:
Das MacBook einer fremden/externen Person bringt das interne Netzwerk komplett zum erliegen.
Deswegen lässt man "solche" nur in ein Gast-(W)LAN.
lg,
Slainte
ich fasse kurz zusammen:
Das MacBook einer fremden/externen Person bringt das interne Netzwerk komplett zum erliegen.
Deswegen lässt man "solche" nur in ein Gast-(W)LAN.
Vielleicht habt ihr Ideen.
Gehackt, Trojaner, Spieltrieb, Script-Kiddie, defekte Hardware und/oder Treiber... auf einen Endgerät das du nicht selbst kontrollierst kann das alles sein.lg,
Slainte
Zitat von @SlainteMhath:
Moin,
ich fasse kurz zusammen:
Das MacBook einer fremden/externen Person bringt das interne Netzwerk komplett zum erliegen.
Deswegen lässt man "solche" nur in ein Gast-(W)LAN.
Moin,
ich fasse kurz zusammen:
Das MacBook einer fremden/externen Person bringt das interne Netzwerk komplett zum erliegen.
Deswegen lässt man "solche" nur in ein Gast-(W)LAN.
Wenn ich das richtig verstanden habe ist das ein Gäste-WLAN.
Liest sich wie Hotel oder Cafe-WLAN.
lks
Bei Gäste LANs deaktiviere ich grundsätzlich dynamisches ARP am Router stelle auf static ARP und lasse den Router nur die DHCP Leases automatisch in die ARP Tabelle eintragen, und aktiviere natürlich Client-Isolation, dann passiert sowas wie oben erst gar nicht.
1Wenn ich das richtig verstanden habe ist das ein Gäste-WLAN.
Liest sich wie Hotel oder Cafe-WLAN.
Habe ich eigentlich anhand dieses Satzes:Liest sich wie Hotel oder Cafe-WLAN.
Einige Benutzer beklagten sich, dass sie das Netzwerk nicht mehr nutzen konnten, weder verkabelt noch WiFi.
ausgeschlossen ;)
Oder da läuft irgendeine Software für Virtualisierung, die diesen IP-Range benutzt.
Zitat von @SlainteMhath:
ausgeschlossen ;)
Wenn ich das richtig verstanden habe ist das ein Gäste-WLAN.
Liest sich wie Hotel oder Cafe-WLAN.
Habe ich eigentlich anhand dieses Satzes:Liest sich wie Hotel oder Cafe-WLAN.
Einige Benutzer beklagten sich, dass sie das Netzwerk nicht mehr nutzen konnten, weder verkabelt noch WiFi.
ausgeschlossen ;)
Vielleicht ist ja der TO so nett, zu sagen, wessen Kristallkugel besser funktioniert.
lks
Zitat von @Lochkartenstanzer:
Vielleicht ist ja der TO so nett, zu sagen, wessen Kristallkugel besser funktioniert.
Vielleicht ist ja der TO so nett, zu sagen, wessen Kristallkugel besser funktioniert.
Der hat vermutlich schon eine Verabredung mit einem "Alternate Rendevouz Point"
.1
Servus!
Also eine echte Erklärung für dein Problem hab ich nicht...
Allerdings hatten wir - ähnlich großes Netzwerk - fast die gleichen Probleme.
Apple Geräte haben bei uns mit massiven MDNS Broadcasts unsere Switche lahmgelegt bzw. die ARP-Tabellen der Geräte kaputt gemacht.
Lösung:
An den WLAN-Accesspoints MDNS blockieren, und da nicht nur Apple-Geräte MDNS machen: Windows Firewall angepasst und geblockt per GPO
evlt. gehts ja bei euch auch in die Richtung - Wireshark hilft...
Gruß
Luigi
Also eine echte Erklärung für dein Problem hab ich nicht...
Allerdings hatten wir - ähnlich großes Netzwerk - fast die gleichen Probleme.
Apple Geräte haben bei uns mit massiven MDNS Broadcasts unsere Switche lahmgelegt bzw. die ARP-Tabellen der Geräte kaputt gemacht.
Lösung:
An den WLAN-Accesspoints MDNS blockieren, und da nicht nur Apple-Geräte MDNS machen: Windows Firewall angepasst und geblockt per GPO
evlt. gehts ja bei euch auch in die Richtung - Wireshark hilft...
Gruß
Luigi
Vielen Dank für die vielen Bemerkungen. Ich versuche mehr Informationen zu liefern:
1. Ja, es ist ein Hotelbetrieb und betrifft das freie Gäste WLAN.
2. Wireshark ist super, machen wir immer, wenn wir Zeit haben und die Geräte in unserem Einzug sind.
3. ARP Spoofing, haben wir in Betracht gezogen. Durch die ungefähre Verortung des "Täters" haben wir diesen dann auch gefunden, durch die zeitgenaue Reproduktion und Eleminierung des Fehlers, haben wir das dann als absichtliches ARP Spoofing ausgeschlossen.
Daher auch der Kontakt zum IT Beauftragten des Geräte-Inhabers
4. Settings: Client Isolation findet schon am AP statt.
Static ARP Entries ist meines Verständnisses nach manuelle Zuordnung von Einträgen, daher unpraktikabel.
Ich habe mich auf Deinen Hinweis dennoch damit beschäftigt und kann es so nicht konfigurieren, da ich keine entsprechende Konfiguration finde.
Einfaches anknipsen führt zu Nichterreichbarkeit des Routers, wie Du es vorraus sagtest, allerdings ist dann auch das Captive Portal nicht erreichbar und damit die Grundfunktion unverfügbar.
5. MDNS, hat in diesem Fall nicht gepasst. Wir hatte keine massiven broadcasts zu beklagen sondern vielmehr eine "Identitätskrise", weil der Mac auf Pings an den Router antwortete.
MDNS der Clients stehen nicht in meinem Einzugsgebiet, da es das Gastnetzwerk ist.
Ich danke erstmal allen für den Input. Leider kann ich das nicht nachvollziehen, da das Gerät inzwischen nicht mehr hier ist.
1. Ja, es ist ein Hotelbetrieb und betrifft das freie Gäste WLAN.
2. Wireshark ist super, machen wir immer, wenn wir Zeit haben und die Geräte in unserem Einzug sind.
3. ARP Spoofing, haben wir in Betracht gezogen. Durch die ungefähre Verortung des "Täters" haben wir diesen dann auch gefunden, durch die zeitgenaue Reproduktion und Eleminierung des Fehlers, haben wir das dann als absichtliches ARP Spoofing ausgeschlossen.
Daher auch der Kontakt zum IT Beauftragten des Geräte-Inhabers
4. Settings: Client Isolation findet schon am AP statt.
Static ARP Entries ist meines Verständnisses nach manuelle Zuordnung von Einträgen, daher unpraktikabel.
Ich habe mich auf Deinen Hinweis dennoch damit beschäftigt und kann es so nicht konfigurieren, da ich keine entsprechende Konfiguration finde.
Einfaches anknipsen führt zu Nichterreichbarkeit des Routers, wie Du es vorraus sagtest, allerdings ist dann auch das Captive Portal nicht erreichbar und damit die Grundfunktion unverfügbar.
5. MDNS, hat in diesem Fall nicht gepasst. Wir hatte keine massiven broadcasts zu beklagen sondern vielmehr eine "Identitätskrise", weil der Mac auf Pings an den Router antwortete.
MDNS der Clients stehen nicht in meinem Einzugsgebiet, da es das Gastnetzwerk ist.
Ich danke erstmal allen für den Input. Leider kann ich das nicht nachvollziehen, da das Gerät inzwischen nicht mehr hier ist.
Static ARP Entries ist meines Verständnisses nach manuelle Zuordnung von Einträgen, daher unpraktikabel.
Ein Mikrotik kann das 
. Dem kann man sagen mach Static ARP, aber füge selber die DHCP Leases der Table hinzu und entferne sie sobald sie abgelaufen ist.
Hallo seltsam
ich konnte bei uns den gleichen Effekt mit unterschiedlichen MacBooks beobachten (MacBook verwendet IP des Gateways), bist du hier weitergekommen?
Viele Grüße
Patrick
ich konnte bei uns den gleichen Effekt mit unterschiedlichen MacBooks beobachten (MacBook verwendet IP des Gateways), bist du hier weitergekommen?
Viele Grüße
Patrick
Hallo zusammen und hallo Patrick,
Wir haben es geschafft, ich hatte 2 Monate Auslandsaufenthalt mit Familie, daher poste ich das jetzt erst.
Als Vorspiel haben wir die eingrenzten Apple Geräte dem Support von Apple gemeldet.
Der im übrigen ungestraft als unbrauchbar eingestuft werden kann, zumindest was die Kommunikationskultur betrifft.
Ein Kollege aus meinem engeren netzwerk hat dann mal gewühlt und uns auf "Gratuitous ARP" gebracht.
Dann haben wir mit Wireshark nochmal speziell darauf gezielt und sind fündig geworden.
Es fiel schnell auf, dass insbesondere Apple Netzwerkteilnehmer über diese Funktion unwillkürlich fehlerhafte ARP Pakete verbreiteten, in denen sie Ihrer MacAdresse die IP des Routers zuordneten. Warum auch immer ist bis heute unklar.
Hier eine Erklärung zum Gratuitous ARP als solches:
https://www.practicalnetworking.net/series/arp/gratuitous-arp/
Da wir ein WLAN Netzwerk mit rund 300 Access Points betreiben, fiel es uns schwer, einen Übeltäter klar zu identifizieren.
Darum war das zeitweise resetten eines WLAN im 700 Zimmer Hotel immer nur eine Notfalllösung.
Da sich die Vorfälle aber häuften, mussste das final gelöst werden.
Zur Lösung:
Sofern man keine hochverfügbaren Routingszenarien verwendet, sollte man in seinem Netzwerk die Gratuitous ARP Broadcasts unterdrücken.
Dazu braucht man natürlich entsprechende Hardware, die das unterstützt.
Wir konnten das bei uns im Netz nach einen FW Update auf den AP's zu 80 % umsetzen.
Ältere Accesspoints sind nicht in der Lage, die FW zu verwenden, daher haben wir diese noch als Fehlerquelle auf dem Schirm und müssen da tauschen.
Sollten eure AP das nicht können, kann man das noch auf Switchen unterdrücken, dann greift das nur ab dem Switch.
Wir verwenden Lancom Komponenten, da gibt es ab der FW 10.x einen Schalter bei dem man Gratuitous ARP ignorieren kann.
Das wird bei anderen Herstellern jedoch anders gelöst oder nicht möglich sein.
Wir konnten das hier zentral über den Controller per Script steuern.
Wer dazu Infos braucht, kann sich gern nochmal melden.
Für uns wäre es noch interessant zu wissen, ob andere Hersteller (PatrickHoeft???) auch darunter zu leiden haben oder ob dieses Problem nur bei Lancom zu finden ist?
Ich hoffe, das hier hilft auch weiteren Kollegen.
Viele Grüße aus Berlin.
Wir haben es geschafft, ich hatte 2 Monate Auslandsaufenthalt mit Familie, daher poste ich das jetzt erst.
Als Vorspiel haben wir die eingrenzten Apple Geräte dem Support von Apple gemeldet.
Der im übrigen ungestraft als unbrauchbar eingestuft werden kann, zumindest was die Kommunikationskultur betrifft.
Ein Kollege aus meinem engeren netzwerk hat dann mal gewühlt und uns auf "Gratuitous ARP" gebracht.
Dann haben wir mit Wireshark nochmal speziell darauf gezielt und sind fündig geworden.
Es fiel schnell auf, dass insbesondere Apple Netzwerkteilnehmer über diese Funktion unwillkürlich fehlerhafte ARP Pakete verbreiteten, in denen sie Ihrer MacAdresse die IP des Routers zuordneten. Warum auch immer ist bis heute unklar.
Hier eine Erklärung zum Gratuitous ARP als solches:
https://www.practicalnetworking.net/series/arp/gratuitous-arp/
Da wir ein WLAN Netzwerk mit rund 300 Access Points betreiben, fiel es uns schwer, einen Übeltäter klar zu identifizieren.
Darum war das zeitweise resetten eines WLAN im 700 Zimmer Hotel immer nur eine Notfalllösung.
Da sich die Vorfälle aber häuften, mussste das final gelöst werden.
Zur Lösung:
Sofern man keine hochverfügbaren Routingszenarien verwendet, sollte man in seinem Netzwerk die Gratuitous ARP Broadcasts unterdrücken.
Dazu braucht man natürlich entsprechende Hardware, die das unterstützt.
Wir konnten das bei uns im Netz nach einen FW Update auf den AP's zu 80 % umsetzen.
Ältere Accesspoints sind nicht in der Lage, die FW zu verwenden, daher haben wir diese noch als Fehlerquelle auf dem Schirm und müssen da tauschen.
Sollten eure AP das nicht können, kann man das noch auf Switchen unterdrücken, dann greift das nur ab dem Switch.
Wir verwenden Lancom Komponenten, da gibt es ab der FW 10.x einen Schalter bei dem man Gratuitous ARP ignorieren kann.
Das wird bei anderen Herstellern jedoch anders gelöst oder nicht möglich sein.
Wir konnten das hier zentral über den Controller per Script steuern.
Wer dazu Infos braucht, kann sich gern nochmal melden.
Für uns wäre es noch interessant zu wissen, ob andere Hersteller (PatrickHoeft???) auch darunter zu leiden haben oder ob dieses Problem nur bei Lancom zu finden ist?
Ich hoffe, das hier hilft auch weiteren Kollegen.
Viele Grüße aus Berlin.
Zitat von @seltsam:
Sofern man keine hochverfügbaren Routingszenarien verwendet, sollte man in seinem Netzwerk die Gratuitous ARP Broadcasts unterdrücken.
Sofern man keine hochverfügbaren Routingszenarien verwendet, sollte man in seinem Netzwerk die Gratuitous ARP Broadcasts unterdrücken.
Man sollte generell seine Endgeräte so einstellen, daß die nicht auf Gratuitous ARP reagieren, sondern nur auf selbst abgeschickte arp-request. damit führt man arp-spoofing/-poisoning durch.
Ist aber schon seit dem letzten Jahrtaused bekannt.
lks
Ach - und wie mach der Herr das mit Geräten die er nicht unter Kontrolle hat - wie hier - Hotel?
Zitat von @126231:
Ach - und wie mach der Herr das mit Geräten die er nicht unter Kontrolle hat - wie hier - Hotel?
Ach - und wie mach der Herr das mit Geräten die er nicht unter Kontrolle hat - wie hier - Hotel?
Komtm auf die Gegebenheiten an. Aber letztendlich ist jeder Gast für sein eigenes Gerät verantwortlich.
lks
Hallo zusammen,
leider kann ich keine Auskunft darüber geben wie es sich mit anderen Herstellern verhält da wir selbst auch LANCOM einsetzen, ich habe bei uns diese Config vorgenommen ob es funktioniert kann ich erst in ein paar Tagen sagen.
@seltsam: Vielen Dank für den wertvollen Tipp
Viele Grüße
Patrick
leider kann ich keine Auskunft darüber geben wie es sich mit anderen Herstellern verhält da wir selbst auch LANCOM einsetzen, ich habe bei uns diese Config vorgenommen ob es funktioniert kann ich erst in ein paar Tagen sagen.
@seltsam: Vielen Dank für den wertvollen Tipp
Viele Grüße
Patrick
