Fritzbox, WLAN und Unique Local Addresses

Yamagi

Possessed With Psi Powers
Teammitglied
Moin Moin,
ich habe hier ein etwas ... interessantes Problem. :) Und zwar habe ich ein recht einfaches Netzwerk: An der sozusagen Front steht eine Fritzbox 7530 AX mit dem aktuellen FritzOS 7.29. Sie verbindet zu einem normalen Telekom Endkundenanschluss und bekommt von dort eine IPv4-Adresse und ein IPv6-Präfix. Beides ist dynamisch. Die Fritzbox stellt WLAN zur Verfügung, in Sachen verkabeltem Netz ist sie mit einem Cisco SG-200-08 Switch verbunden. Alle verkabelten Geräte hängen an dem Cisco Switch.

Die Fritzbox verteilt an alle Stationen im Netz, egal ob verkabelt oder WLAN:
  • Eine IPv4-Adresse per DHCP.
  • Das öffentliche IPv6-Präfix der Telekom per SLAAC.
  • Ein Unique Local Präfix per SLAAC.

Das Unique Local Präfix ist notwendig, damit die Stationen sich eine statische Unique Local Address (ULA) ableiten können. Da das IPv6-Präfix der Telekom dynamisch ist, würden sich sich sonst die Adressen der Stationen ändern, wenn sich das Präfix ändert. Was doof wäre.

Das funktioniert auch wunderbar, solange ich mich zwischen verkabelten Geräten bewege. Stationen, die im WLAN hängen, haben allerdings das Problem, dass TCP-Verbindungen auf ULA nach wenigen Sekunden abreißen. Und nur auf ULA. Als Beispiel von einem Laptop im WLAN aus auf eine Maschine im verkabelten Netz:
  • ssh $ipv4 geht.
  • ssh $telekompräfix geht.
  • ssh $ula reißt nach wenigen Sekunden ab.

Dieser Abriss ist schön mit tcpdump zu sehen, beide Seiten erhalten keine Pakete der Gegenseite mehr. Sie sehen sich einfach nicht mehr. Wenn ich eine zweite SSH-Verbindung per ssh $ula parallel zur ersten öffne, kommt die hängende erste Verbindung manchmal, aber nicht immer, wieder hoch. In dem Fall gehen über die erste und zweite Verbindung wieder für einige Sekunden Pakete, bis beide Verbindungen wieder abreißen.

Es betrifft ausschließlich die UL-Adressen. IPv4-Adressen und aus dem Telekom-Präfix generierte Adressen funktionieren. Es ist unabhängig vom Betriebssystem, sowohl FreeBSD, Linux und Windows sind betroffen. Es ist auch unabhängig der Hardware, es tritt mit Realtek- und Intel-NICs auf, sowie Intel- und Mediatek-WLAN-Karten. Dem Verhalten nach riecht es etwas nach Kollision, ich kann Adresskollisionen der ULA allerdings ausschließen. Händisch abgeglichen, auch wenn sie dank SLAAC eh nicht möglich sein sollten. Ich habe auch die MAC-Adressen abgeglichen, auch dort wie erwartet keine Kollisionen. Es sind keine Router oder Paket-Filter, die Ärger machen könnten, im Weg. Zum Zeitpunkt des Abbruchs ändern sich die UL-Adressen nicht. Es reißt auch ab, wenn die UL-Adressen noch >1000 Sekunden Lifetime haben. Auf FreeBSD rtsold laufen oder nicht laufen zu lassen, macht keinen Unterschied.

Bleibt die Fritzbox. Die logischste Erklärung wäre, dass sie die zwischen WLAN und verkabelten Netz vermittelten (gebridgten?) Verbindungen zwischen zwei UL-Adressen droppt oder in ihrem wahrscheinlich vorhandenen Paketfilter blockiert. Aber warum sollte sie das tun? Und warum nur mit ULA? Es wäre dann vermutlich ein Bug. Da das FritzOS 7.29 jetzt aber schon ein halbes Jahr alt ist, hätte es jemanden auffallen müssen. Oder zumindest sollen. Die Fritzboxen sind ja sehr weit verbreitet, auch bei "versierten" Nutzern. Google findet allerdings nichts oder ich habe die falschen Suchbegriffe.

Daher meine Frage: Hat jemand von eine kluge Idee? :)
 

morromett

Well-Known Member
Bleibt die Fritzbox. Die logischste Erklärung wäre, dass sie die zwischen WLAN und verkabelten Netz vermittelten (gebridgten?) Verbindungen zwischen zwei UL-Adressen droppt oder in ihrem wahrscheinlich vorhandenen Paketfilter blockiert. Aber warum sollte sie das tun? Und warum nur mit ULA?
Passiert das auch, wenn Du in den per WLAN verbundenen Geräten, statische (permanente) neighbor-cache-Eintragungen für die ULAs machst?

EDIT:

Versuch mal auch mit einem Linux-Gerät (das per WLAN verbunden ist), z. B. minütlich per cronjob, ein nicht angefordertes neighbor advertisement (NDP-packet) für seine ULA, ins Subnetz (W/LAN) der FritzBox zu senden.
 

mr44er

moderater Moderator
Teammitglied
Hast du mal diese Filter (Internet->Filter->Listen->Globale Filtereinstellungen) testweise abgedreht? Da steht ja nur oberflächlich dabei, was sie tun sollten. Der für teredo sticht etwas ins Auge.

Erreichst du aus dem WLAN die Oberfläche der Box und funktioniert der login? Fritzboxen behandeln das unterschiedlich, von wo man reinkommt und sollten das normalerweise bemeckern. Entweder direkt per Infotext oder via Aufforderung nach user+pw, obwohl man nur ein Passwort (ohne login) gesetzt hat.
Recht exotisch war mal (System->Fritzbox-Benutzer->Zusätzliche Bestätigung->Haken raus) für einen weiteren SIPacc aus nem anderen Netz.

Edit: Oder der MAC-Filter baut Mist auf Basis der ULA. Fischers Fritzbox fischt neue Bugs oder so. :)
 

morromett

Well-Known Member
Wenn ich eine zweite SSH-Verbindung per ssh $ula parallel zur ersten öffne, kommt die hängende erste Verbindung manchmal, aber nicht immer, wieder hoch. In dem Fall gehen über die erste und zweite Verbindung wieder für einige Sekunden Pakete, bis beide Verbindungen wieder abreißen.
Welche Ausgabe bzw. Fehlermeldung gibt es evtl., wenn Du
Code:
ssh -vvv $ula
benutzt?
Hast Du ssh auch schon mit ipv6-only:
Code:
AddressFamily inet6
versucht und auf Server- und Client-Seite, die keepalive-Konfigurationsmöglichkeiten benutzt?
 

Yamagi

Possessed With Psi Powers
Teammitglied
Passiert das auch, wenn Du in den per WLAN verbundenen Geräten, statische (permanente) neighbor-cache-Eintragungen für die ULAs machst?

Erstmal hätte ich selbst auf NDP kommen können. Danke für den Hinweis auf das Offensichtliche... Die automatisch ermittelten Einträge im Neighboor-Cache sind auf meinem Linux-Laptop im WLAN korrekt und sie fallen auch nicht aus oder werden auf STALE gesetzt, wenn die Verbindung abreißt. Sie bleiben REACHABLE. Ich habe trotzdem einmal einen manuellen STATIC Eintrag gemacht, aber wie erwartet ohne Änderung.

Gleiches auch auf der Gegenseite im verkabelten Netz. Der Eintrag ist da und er ist REACHABLE.

Versuch mal auch mit einem Linux-Gerät (das per WLAN verbunden ist), z. B. minütlich per cronjob, ein nicht angefordertes neighbor advertisement (NDP-packet) für seine ULA, ins Subnetz (W/LAN) der FritzBox zu senden.
Auch das ändert nichts. Egal ob ich alle 120, alle 60 oder nur alle 10 Sekunden per ndptool ein Unsolicited NA sende, die Verbindung reißt trotzdem ab. Unabhängig davon sieht die Fritzbox unter Heimnetzwerk -> Netzwerk -> Gerät anklicken die ULA dauerhaft. Wobei ich nicht weiß, was die Anzeige wert ist. Kann auch sein, dass die unabhängig von NDP ist.

Erreichst du aus dem WLAN die Oberfläche der Box und funktioniert der login? Fritzboxen behandeln das unterschiedlich, von wo man reinkommt und sollten das normalerweise bemeckern. Entweder direkt per Infotext oder via Aufforderung nach user+pw, obwohl man nur ein Passwort (ohne login) gesetzt hat.
Ja, das funktioniert, auch über die ULA. Über die ULA auf das Webinterface der Fritzbox verbunden zu sein und es zu beschäftigen, damit Daten übertragen werden, verhindert nicht, dass die SSH-Verbindung über die Fritzbox abreißt.

Ich habe den Zugangstyp des Laptop nochmal zur Sicherheit von "Standard" auf "Unbeschrängt" gestellt, aber auch das ändert nichts. Hätte mich auch gewundert.

Welche Ausgabe bzw. Fehlermeldung gibt es evtl., wenn Du
Code:
ssh -vvv $ula
benutzt?
Keine, die Verbindung friert einfach ein. Erst nach langer Zeit kommt ein client_check_window_change: changed.

Hast Du ssh auch schon mit ipv6-only:
Code:
AddressFamily inet6
versucht und auf Server- und Client-Seite, die keepalive-Konfigurationsmöglichkeiten benutzt?
Ich habe es mit ssh -6 probiert, um sicher zu sein, dass er keinen Mist baut. Aber auch das ändert nichts. KeepAlive kann ich nachher gerne nochmal probieren. Es würde mich aber wundern, wenn es hilft. Auch wenn ich die Verbindung beschäftige und Ausgabe generiere (while : ; do date ; sleep 1 ; done) stirbt die Verbindung nach weniger als einer Minute. Oft in unter 30 Sekunden.

Ich stochere nachher nochmal in Richtung NDP. Wobei meine Möglichkeiten begrenzt sind, da die Fritzbox anscheinend keine Möglichkeit hat die Tabelle auszugeben oder irgendwie manuell einzugreifen.
 

morromett

Well-Known Member
Auch das ändert nichts. Egal ob ich alle 120, alle 60 oder nur alle 10 Sekunden per ndptool ein Unsolicited NA sende, die Verbindung reißt trotzdem ab. Unabhängig davon sieht die Fritzbox unter Heimnetzwerk -> Netzwerk -> Gerät anklicken die ULA dauerhaft. Wobei ich nicht weiß, was die Anzeige wert ist. Kann auch sein, dass die unabhängig von NDP ist.
Was man noch probieren könnte (als temporärer test), ist z. B. alle 60 Sekunden vom ssh-Client-Gerät zum sshd-Server-Gerät (bei involvierter WLAN-Verbindung zw. den Geräten), ein neighbour-solicitation-Paket (NS mit dem ndptool oder gleichwertig) zu senden. Parallel/gleichzeitig mit dem ndptool im monitor-Modus oder mit tcpdump sniffen/schauen, ob das andere Gerät auf das NS-Paket mit einem NA-Paket antwortet. Dann weiß man evtl., dass nur die ssh-Verbindung (tcp6) betroffen ist.
EDIT: Evtl. auch mal ohne Switch an der FB testen. Wird für die WLAN-Verbindung nur bzw. von allen WLAN-Geräten, wifi-6 benutzt?

EDIT2:

Hast Du privacy extensions (PE) aktiviert? Wenn ja, dann auch mit deaktivierten PEs probieren (... obwohl das bei SLAAC keine Rolle spielen dürfte, aber man weiß ja nie ...).
 

Columbo0815

Kaffeemann
Teammitglied
Ich verstehe das Problem noch nicht einmal. Allerdings ist die aktuellste Firmware die 7.31. Auch für die 7530 AX. Als updategeiler Ahnungsloser würde ich zuerst die neueste Firmware testen...
 

Yamagi

Possessed With Psi Powers
Teammitglied
Hast Du privacy extensions (PE) aktiviert?
Nein, keine PE.

EDIT: Evtl. auch mal ohne Switch an der FB testen. Wird für die WLAN-Verbindung nur bzw. von allen WLAN-Geräten, wifi-6 benutzt?
Die meisten WLAN-Geräte sind WiFi-5, WiFi-6 Geräte habe ich gar nicht. Geräte im verkabelten Netz sind generell nicht betroffen, egal ob sie direkt an die Fritzbox oder an den Cisco-Switch angeschlossen sind. Zwei WLAN-Geräte untereinander haben das Problem ebenfalls. Es tritt nicht auf, wenn parallel zur sonst abreißenden tcp6-Verbindung (getestet mit SSH und HTTP) icmp6 echo Requests geschickt werden. Sie die Stationen also pingen, Richtung ist egal. NS <-> NA scheinen ebenfalls immer durchzugehen.

Ich habe jetzt erstmal meinen Travel Router (so ein TP-Link Dings, was man zum Erweitern von Hotel-WLANs nehmen kann) genommen und als Access Point ins Netz gehängt. Damit tritt es nicht auf. Das zieht die Schlinge für die Fritz weiter zu, denn wäre es ein obskures Problem mit NDP oder ähnlichem, müsste es unabhängig vom Access Point sein.

Jetzt erstmal @Columbo0815s Firmwareupdate. Das gab es gestern gegen 16 Uhr definitiv noch nicht.
 

morromett

Well-Known Member
Zwei WLAN-Geräte untereinander haben das Problem ebenfalls. Es tritt nicht auf, wenn parallel zur sonst abreißenden tcp6-Verbindung (getestet mit SSH und HTTP) icmp6 echo Requests geschickt werden. Sie die Stationen also pingen, Richtung ist egal. NS <-> NA scheinen ebenfalls immer durchzugehen.
Schau mal auf einem Linux-Gerät, ohne und mit icmp6-Ping zwischen den Stationen (d. h. auch wenn die "ssh -6"-Verbindung schon abgebrochen ist bzw. nicht mehr statt findet), wie die Ausgaben von:
Code:
ip -6 route show
ip -6 route get <ULA-andere-Station>
sind bzw. ob evtl. ein Unterschied im Routing erkennbar ist.
 

Yamagi

Possessed With Psi Powers
Teammitglied
Tada, sie ändern sich wirklich. Die Route für das Netz im Routing Table bleibt gleich:

Code:
fdd0:xxxx:xxxx:1::/64 via fe80::1eed:xxxx:xxxx:f4c8 dev br0 proto ra metric 425 pref medium

fdd0:xxxx:xxxx:1::/64 ist das Netz mit den ULA, fe80::1eed:xxxx:xxxx:f4c8 ist die Link Local Adresse der Fritzbox. Aus Paranoia-Gründen ein paar Blöcke zensiert. Die Hostroute ist dann auch:

Code:
fdd0:xxxx:xxxx:1:xxxx:xxxx:xxxx:8bd0 from :: via fe80::1eed:xxxx:xxxx:f4c8 dev br0 proto ra src fdd0:xxxx:xxx:1:xxxx:xxxx:xxxx:f90a metric 425 pref medium

Sobald ich per SSH verbinde, ändert sich die Hostroute:

Code:
fdd0:xxxx:xxxx:1:xxxx:xxxx:xxxx:8bd0 from :: dev br0 src fdd0:xxxx:xxxx:1:xxxx:xxxx:xxxx:f90a metric 425 pref medium

Also direkt. Irgendwann schwenkt sie zurück auf die Link Local Adresse der Fritzbox und damit reißt SSH ab:

Code:
fdd0:xxxx:xxxx:1:d7d9:3b8:49ec:8bd0 from :: via fe80::1eed:xxxx:xxxx:f4c8 dev br0 proto ra src fdd0:xxxx:xxx:1:xxxx:xxxx:xxxx:f90a metric 425 pref medium

Nachtrag, da eben vergessen: Wenn ich pinge, schwenkt die Route nicht zurück. Sie bleibt wie weiter oben, also direkt.

Ich muss zugeben, dass mein IPv6-Foo mich an dieser Stelle dann doch verlässt. Das ist zu tief drin und meine IPv6-Erfahrung zu gering. Soll das so? :)
 

morromett

Well-Known Member
Irgendwann schwenkt sie zurück auf die Link Local Adresse der Fritzbox und damit reißt SSH ab:
Und wenn Du den icmp6-Ping machst, dann schwenkt sie nicht zurück (auf die LLA der FB) bzw. die ssh-Verbindung reißt nicht ab?
Und das passiert auch nur, wenn eine WLAN-Verbindung benutzt wird und nicht bei Kabelverbindung? Das ist schon seltsam.

EDIT:

... und auch nur im WLAN der FB, denn mit dem TP-Link hast Du diese v6-Probleme ja nicht.
 

Yamagi

Possessed With Psi Powers
Teammitglied
nd wenn Du den icmp6-Ping machst, dann schwenkt sie nicht zurück (auf die LLA der FB) bzw. die ssh-Verbindung reißt nicht ab?
Und das passiert auch nur, wenn eine WLAN-Verbindung benutzt wird und nicht bei Kabelverbindung? Das ist schon seltsam.
Die LLA der Fritzbox antwortet leider nicht ICMP6 ECHO. Der Ping war zwischen den beiden Stationen. Das reicht aus, damit die Route nicht zurückschwenkt und die Verbindung reißt nicht ab.

Ich habe nochmal mit FreeBSD statt Linux getestet. FreeBSD <-> Linux reißt ab, da die Route auf der Linux-Seite schwenkt. Nicht aber auf der FreeBSD-Seite, dort bleibt es durchgehend bei einer Interface-Route über die NIC, genauer gesagt wlan0. FreeBSD <-> FreeBSD reißt dann tatsächlich auch gar nicht ab, da auf keiner beiden Seiten die Route schwenkt. Den FreeBSD <-> FreeBSD Fall hatte ich bisher einfach nicht getestet, daher fiel es mir nicht auf.

NACHTRAG: Sind beide Stationen verkabelt, schwenkt die Route genauso. Allerdings führt es nicht zum Abriss. Sie schwenkt einfach wieder zurück und die Verbindung bleibt bestehen. Also wirklich die Fritzbox, die etwas blockt, was sie nicht blocken soll?
 
Zuletzt bearbeitet:

Yamagi

Possessed With Psi Powers
Teammitglied
Um nach etwas weiterem Gebastel und Gestochere nochmal eine Art Abschluss zu geben:
  • NetworkManager baut Mist. Pötteringware halt. Die Fritzbox schickt ihm per Router Advertisement das Telekom-Prefix und das Unique Local Präfix, außerdem für beide Präfixe eine Route über die Link Local Adresse der Fritzbox. NetworkManager generiert aus dem Telekom-Prefix seine primäre Adresse und aus dem Unique Local Prefix eine sekundäre Adresse. Außerdem setzt er unnötigerweise die beiden Routen, FreeBSDs rtsol und Linux systemd-netword ignorieren sie. Soweit, so gut, kann man machen. Aber: Für die primäre Adresse fügt NetworkManager eine Interface Route hinzu, für die sekundäre Adresse nicht. Daher funktionieren die Telekom-Adressen, denn es wird die Interface Route genommen und damit tritt das Schwenken der Routen nicht auf. Die ULA funktionert nicht, denn dort geht die Route über die LLA der Fritzbox, was zu diesem Schwenken führt.
  • Die Fritzbox baut beim Schwenken der Routen auf WLAN-Seite Mist, aber nicht auf verkabelter Seite. Daher funktionieren die ULA, wenn beide Stationen im verkabelten Teil des Netzes sind. Aber nicht, wenn sich eine Station im WLAN-Teil befindet. Denn dort macht die Fritzbox nach dem zweiten Schwenk - dem Rückschwenk - der Routen dicht. Das erste Paket geht auf die LLA der Fritzbox, das geht durch die Fritzbox durch. Dann passiert Magie und es wird auf den direkten Weg ohne Fritzbox geschwenkt. Noch ist alles gut. Dann passiert nochmal Magie, es geht zurück auf die LLA der Fritzbox. Aus dem verkabelten Netz klappt es, aus dem WLAN macht die Fritzbox sofort dicht.
Weiß man das, kann man einen Würg-Around frickeln:
  • Im NetworkManager konfigurierte statische IPs bekommen immer eine Interface Route mit Priorität medium zugewiesen. Man kann der Fritzbox unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IPv6 Einstellungen sagen, dass sie den per Router Advertisement verteilten Routen Priorität low zuweisen soll. Damit sind die immer unter den Interface Routen.
  • Anschließend setzt man im NetworkManager die generierte ULA einfach statisch auf das Interface. NetworkManager legt eine Interface Route an, deren Priorität ist immer höher als die Routen, die von der Fritzbox kommen. Damit muss nicht geschwenkt werden und Problem gelöst. Da Unique Local Prefixes eben ausreiched unique seinen sollten und ich meines zufällig generiert habe, dürfte das (auf dem Laptop) auch keinen Ärger machen, wenn ich mal nicht zu Hause bin.

Da es effektiv nur zwei Stationen in meinem Netz betrifft, kann ich mit dem Work Around leben. Aber war die Odyssee nicht schön? Nein, war sie nicht. Vielen Dank an @morromett für die richtige Spur und @mr44er für den Tipp nochmal tiefer in die IPv6-Einstellungen der Fritzbox zu schauen. :)
 
Zuletzt bearbeitet:

morromett

Well-Known Member
Die LLA der Fritzbox antwortet leider nicht ICMP6 ECHO.
Beim Ping6 auf eine LLA muss eine andere Syntax benutzt werden:
Code:
ping6 -c 3 -W 3 <LLA>%<Interface>
Aber evtl. hast Du das ja so gemacht. Hat die FritzBox keine ULA, die Du v6-pingen könntest? In der Ausgabe (des neighbor-cache) von:
Code:
ip n s
, sollte die ULA der FritzBox ersichtlich sein.
FreeBSD reißt dann tatsächlich auch gar nicht ab, da auf keiner beiden Seiten die Route schwenkt.
Da stellt sich die Frage, warum schwenkt die Route mit Linux (bei Benutzung des WLAN der FritzBox) und mit welcher manuellen Konfiguration könnte man das evtl. auf dem Linux-Gerät, ändern bzw. verhindern?
Wie ist es mit Linux, im WLAN der TP-Link? ... kein schwenken der Route oder wenn doch, dann schwenkt sie wieder zurück?

EDIT:

Habe deinen Beitrag #14, erst nach dem erstellen meines Beitrags #15, gesehen.
 
Oben