Fritzbox reagiert unter IPv6 nicht auf jeden Ping - Verbindungen hakeln

[DeathAndPain]

Hallo zusammen,

ich habe ein sehr merkwürdiges Problem. In meiner 7590 mit OS 07.29 (will nicht updaten, und diese Version ist ja jahrelang auf Millionen Fritzboxen gelaufen) habe ich IPv4 und IPv6 aktiviert. Im Grundsatz funktioniert das auch, doch bei Verbindungen über IPv6 ist die Reaktion oft hakelig. Ich konnte nun sehen, woran das liegt. Per IPCONFIG habe ich auf meinem Windows-PC gesehen, welche Defaultrouter-IPs die Fritzbox vergibt. Seltsamerweise sind da gleich zwei Link-lokale IPv6-Adressen dabei:

Default Gateway . . . . . . . . . : fe80::fe40:dd7d:24fc:74c5%4
                                    fe80::7642:7fff:fea2:ee62%4
                                    192.168.9.1

Die müssen ja beide zur Fritzbox gehören, wenn sie sie per DHCPv6 als Default-Gateways propagiert. (Einen Weg, direkt auf der Fritzbox ihre eigenen link-lokalen (fe80...)-Adressen einzusehen, habe ich nicht gefunden. Lediglich ihre ULA-Adresse (fd00...) zeigt sie in der IPv6-Konfiguration an.)

Wenn ich nun von meinem PC aus einen Ping auf eine der oben genannten IP-Adressen mache, dann sieht das oft in etwa so aus:

Pinging fe80::fe40:dd7d:24fc:74c5 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Reply from fe80::fe40:dd7d:24fc:74c5: time=1ms
Reply from fe80::fe40:dd7d:24fc:74c5: time=1ms

Wenn ich dieselbe Adresse kurz hintereinander mehrfach anpinge, dann reagiert sie bei den weiteren Versuchen zuverlässig. Pinge ich die Fritzbox hingegen über ihre IPv4-Adresse an, dann reagiert sie sofort und zuverlässig. Genauso zuverlässig reagiert sie, wenn ich sie über ihre ULA-IPv6-Adresse anpinge. Per DHCPv6 gibt sie aber offenbar nur ihre link-lokalen IPv6-Adressen an die Clients heraus, deren Verbindungen dadurch hakeln.

Es gelingt mir nicht, dieses Verhalten zu erklären.

• Wenn die link-lokalen IPv6-Adressen nicht richtig konfiguriert wären, dürften sie überhaupt nicht funktionieren und nicht mit Verzögerung. (Abgesehen davon kenne ich keinen Weg, die link-lokalen IPv6-Adressen in der Fritzbox manuell einzustellen. Lediglich ein Präfix kann man vorgeben.)
• Wenn ich ein physisches Problem (Netzwerkkabel etc.) hätte, müssten die IPv4-Adresse und die ULA-Adresse genauso hakeln.
• Warum hat die Fritzbox auf der Leitung zu meinem PC überhaupt gleich zwei link-lokale IPv6-Adressen?

Woran kann das liegen? Was kann ich tun?

 

[Barungar]

1. Finde ich es bedenklich, dass Dein "ipconfig /all" zwei default gateways im IPv6 zeigt. Das ist nicht sauber.
2. Ist Dein "ping" nicht ganz korrekt. Der korrekte lautet: ping fe80::fe40:dd7d:24fc:74c5%4

Per Standard muss, da eine LLA nicht eineindeutig ist, stets auch die Schnittstelle, die den Ping ausführen soll (daher das %4) mit angegeben werden.

Warum hat die Fritzbox auf der Leitung zu meinem PC überhaupt gleich zwei link-lokale IPv6-Adressen?

Nur aus der Information, dass Dein PC (?) zwei IPv6 default gateways hat, heißt nicht, dass beides von der FritzBox kommt. Aus der Ferne ist es nicht so leicht sowas zu erraten. Dafür wäre es interessant, welche MAC hinter den beiden LLA steckt. Das könntest Du mal prüfen.

Bei der Bestimmung der LLA hält sich AVM grundsätzlich an die EUI-64-Regel, daher müsste die fe80::7642:7fff:fea2:ee62%4 die LLA der FritzBox sein. Die andere LLA, die bei Dir als default gateway geführt wird, ist nämlich keine EUI-64.

P.S.: Wo zeigt die FritzBox ihre ULA?

Einen Weg, direkt auf der Fritzbox ihre eigenen link-lokalen (fe80...)-Adressen einzusehen, habe ich nicht gefunden. Lediglich ihre ULA-Adresse (fd00...) zeigt sie in der IPv6-Konfiguration an.

Ich finde da bei meiner FritzBox keine Stelle, wo sie ihre ULA zeigt... oder ich bin blind.

 

[DeathAndPain]

Das hast Du gesagt. Es ist aber zugegebenermaßen auch etwas gemein gemacht; ich habe es auch erst auf den dritten Blick gesehen, da die Fritzbox die ULA in dem Font darstellt, den sie sonst für statischen Webseitentext verwendet.

Bei der Bestimmung der LLA hält sich AVM grundsätzlich an die EUI-64-Regel, daher müsste die fe80::7642:7fff:fea2:ee62%4 die LLA der FritzBox sein.

ich habe jetzt noch etwas hin- und herkonfiguriert und insbesondere im Pi Hole den Haken "Enable IPv6 support (SLAAC + RA)" entfernt. Vielleicht sendet die RA's, wenn der gesetzt ist, und bezeichnet sich damit (fälschlich) als möglicher Default Router. Damit habe ich auf dem Client jetzt nur noch einen Defaultrouter:

Default Gateway . . . . . . . . . : fe80::7642:7fff:fea2:ee62%4
                                    192.168.9.1

Ein Pingversuch auf fe80::7642:7fff:fea2:ee62 hat dennoch am Anfang wieder Timeouts gebracht, aber dann habe ich mich daran erinnert, dass Du ja meintest, ich solle die %4 mitgeben. Meine Pings auf fe80::7642:7fff:fea2:ee62%4 sind bislang alle durchgegangen. Ob es tatsächlich daran gelegen hat oder das Interface jetzt "warm" war und daher stets geantwortet hat, wird weitere Beobachtung zeigen. Staunen würde ich schon, wenn die Fritzbox nur deshalb sporadisch nicht auf Pings reagieren würde. Aber recht hat immer der, dessen Rat funktioniert. In diesem Falle also Du.

Ist halt ein bisschen unübersichtlich, weil das Pi Hole nur DHCP-Server v4 kann, so dass ich das dort laufen lasse und DHCPv6 auf der Fritzbox selbst.

Auf jeden Fall vielen Dank für Deine Tipps. Minimal haben die mich schon ein Stück weitergebracht, wenn das Problem jetzt nicht sogar schon gelöst ist. Ich werde das beobachten.

 

[Barungar]

Das hast Du gesagt. Es ist aber zugegebenermaßen auch etwas gemein gemacht; ich habe es auch erst auf den dritten Blick gesehen, da die Fritzbox die ULA in dem Font darstellt, den sie sonst für statischen Webseitentext verwendet.

Interessant, bei mir steht da echt gar nix...



Die Zeile "Unique Local Address Ihrer FRITZ!Box:" ist da... aber da steht nix. Ich vermute, dass ich die Zeile daher übersehen habe, da ich sozusagen nach dem Muster fdnn:nnnn:nnnn:nnnn... gesucht habe.

ich habe jetzt noch etwas hin- und herkonfiguriert und insbesondere im Pi Hole den Haken "Enable IPv6 support (SLAAC + RA)" entfernt. Vielleicht sendet die RA's, wenn der gesetzt ist, und bezeichnet sich damit (fälschlich) als möglicher Default Router. Damit habe ich auf dem Client jetzt nur noch einen Defaultrouter:

Das ist sehr wahrscheinlich die Lösung. Das zweite default gateway an Deinem PC war also der PiHole. Wenn Du SLAAC + RA aktivierst, dann verhält sich der PiHole faktisch als Router im IPV6. RA steht nämlich ganz bezeichnend sogar für Router Advertisement (also in Deutsch etwas Router Announce/Anzeige). Damit teilt der PiHole dem Subnetz dann mit, dass er ein IPv6 fähiger Router sei. Alternativ könntest Du es wahrscheinlich auch dadurch lösen, dass Du in der FritzBox in der IPv6-Konfiguration einstellst, dass die FritzBox sich als Router mit Priorität hoch bekanntmachen soll. Ohne die RAs bei Dir mitgesnifft zu haben, vermute ich mal, dass beide Geräte im Standard die mittlere Priorität verwenden.

Ein Pingversuch auf fe80::7642:7fff:fea2:ee62 hat dennoch am Anfang wieder Timeouts gebracht, aber dann habe ich mich daran erinnert, dass Du ja meintest, ich solle die %4 mitgeben. Meine Pings auf fe80::7642:7fff:fea2:ee62%4 sind bislang alle durchgegangen. Ob es tatsächlich daran gelegen hat oder das Interface jetzt "warm" war und daher stets geantwortet hat, wird weitere Beobachtung zeigen.

Das wird höchst wahrscheinlich an dem fehlenden %4 liegen. Ohne diese Angabe weiß der Rechner ja nicht, auf welchem Interface er das Ping-Paket versenden soll. Ein Client mit mehreren Interfaces (und das ist jeder PC) hat auch immer eine rudimentäre Routing-Tabelle, die ihm sagt über welches Interface welches Subnetz erreichbar ist (und auch über welches Interface er das default gateway erreicht).

Im Falle von LLA ist das Subnetz aber immer fe80::/64. Somit ist dieses Subnetz auch stets über jedes Interface des Clients erreichbar. Hier auch mal ein Auszug aus dieser rudimentären Routing-Tabelle (einfach in einem CMD-Fenster mal route print eingeben) meines PCs. Mein PC kann also das Subnetz fe80::/64 über sechs Interfaces erreichen. Welches soll er also nehmen?



Achtung, an dieser Stelle wird es spekulativ. Wenn Du nun eine LLA anpingst ohne Deinem Rechner zu sagen über welches Interface es den Ping senden soll, so wäre eine denkbare Taktik, dass er es auf allen Interfaces versucht. Das würde aber auch bedeuten, dass die Interfaces, die "falsch" waren keine Antwort liefern können und damit zu dem beobachteten Phänomen führen.

Wenn Du eine ULA oder eine GLA anpingst kann Dein Rechner aber stets eineindeutig das Interface bestimmen, das die beste Route zur Verfügung stellt.

 

[DeathAndPain]

Interessant, bei mir steht da echt gar nix...

Sehr seltsam. Welche Firmware-Version verwendest Du?

Das zweite default gateway an Deinem PC war also der PiHole. Wenn Du SLAAC + RA aktivierst, dann verhält sich der PiHole faktisch als Router im IPV6.

Zu diesem Schluss bin ich jetzt auch gelangt. Habe mir das Buch IPv6 gekauft und arbeite mich da allmählich ein. Schon ziemlich kompliziert, aber ich taste mich heran. In diesem Fall habe ich versucht, das Problem zu lösen, indem ich einfach DHCPv6 auf der Fritzbox komplett abschalte und stattdessen auf dem Pi Hole einen DHCPv6-Server aufsetze, so wie es mit IPv4 schon lange gut läuft. Bis ich dann irgendwann auf den Trichter gekommen bin, dass im Gegensatz zu IPv4 nicht der DHCPv6-Server, sondern der RA-Server den Standardgateway bekannt gibt und dabei nur auf sich selber zeigen kann. Damit konnte ich dann alles wieder rückbauen. Aber für den Lerneffekt war es trotzdem nicht schlecht.

Das wird höchst wahrscheinlich an dem fehlenden %4 liegen.

Erklärt natürlich nicht das generell hakelige Internet, denn beim Ansurfen von Webseiten sollte schon das richtige Interface angesteuert werden. Der doppelte Defaultrouter kann freilich durchaus die Antwort sein. Bis jetzt läuft alles flüssig, seitdem er weg ist.

Dafür habe ich allerdings jetzt einen Effekt, der insofern völlig geisteskrank ist, als es keinen für mich auch nur im Ansatz nachvollziehbaren Zusammenhang mit dem oben Diskutierten oder auch meinen Versuchen (DHCPv6-Server und RA-Server auf Pi Hole aufsetzen und dann doch wieder rückbauen) gibt. Und zwar kann man ja das Pi Hole mit dem Befehl pihole -up prüfen lassen, ob es Updates gibt und diese ggf. automatisch einspielen lassen. Das hat auch jahrelang wunderbar funktioniert, aber wenn ich es jetzt mache, geht es so aus:


Auf der einen Seite kann ich beim besten Willen nicht erkennen, was solch eine Überprüfung des Betriebssystems mit IPv6, DHCP oder RA zu tun haben soll. Auf der anderen Seite ist der Zeitpunkt des Auftretens, nämlich genau nach meinem entsprechenden Gebastel und vorher jahrelang nicht, sehr auffällig und deutet darauf hin, dass es mit einiger Wahrscheinlichkeit doch einen Zusammenhang gibt. Wie der beschaffen sein könnte, bin ich freilich am Grübeln. Das in der Fehlermeldung vorgeschlagene

sudo PIHOLE_SKIP_OS_CHECK=true pihole -r

habe ich schon versucht, aber es hat nichts geändert.

Eine Firewall gibt es nicht, wenn man mal von der Standardfunktionalität der Fritzbox absieht.

 

[Barungar]

Sehr seltsam. Welche Firmware-Version verwendest Du?

Fritz!OS 7.31 auf einer FritzBox 7583. Das ist das aktuellste, was es gibt. Ich hätte ja auch ganz gerne das neuere Fritz!OS 7.5x, weil das ein paar nützliche IPv6-Features mehr hat. Dabei ist mir das gehypete WireGuard total egal; ich will die neuen IPsec-Funktionen.

In diesem Fall habe ich versucht, das Problem zu lösen, indem ich einfach DHCPv6 auf der Fritzbox komplett abschalte und stattdessen auf dem Pi Hole einen DHCPv6-Server aufsetze, so wie es mit IPv4 schon lange gut läuft.

Ist (meiner Auffassung nach) im IPv6-Betrieb nicht so die gute Idee. Bei IPv4 kann man den DHCP irgendwo laufen lassen, so lange er nur einen DNS und das Standard Gateway ordentlich mitverteilt. Bei IPv6 läuft das aber anders, da Du im LAN auch echte Global Unicast Addressen verteilst, die ein DHCP hinter dem "Border Router" so ohne weiteres nicht mitbekommt, ist es hier fast schon "Pflicht", dass der "Border Router" das DHCPv6 und das RA (mit höchster Priorität im Subnetz) macht.

Ich betreibe bei mir auch einen eigenen DNS-Server, aber das DHCPv4, DHCPv6 und das RA macht der nicht.

Meine Empfehlung für Dich, wäre an dieser Stelle, starte damit, dass die FritzBox RA und DHCPv6 übernimmt. Du kannst der FritzBox auch mitteilen, welche DNS-Server sie verteilen soll. Im IPv4 macht sie das per DHCPv4 und bei IPv6 verteilt sie den DNS-Server per RA und DHCPv6. Und für beides kannst Du der FritzBox sagen, dass sie die IPs Deines PiHoles nehmen soll. Für das DNSv6 lässt Du am besten die ULA vom PiHole verteilen.

Zusammenhang mit dem oben Diskutierten oder auch meinen Versuchen (DHCPv6-Server und RA-Server auf Pi Hole aufsetzen und dann doch wieder rückbauen) gibt.

Ich kenne Deine volle IPv6-Konfiguration zur Zeit gerade nicht. Aber im IPv6 wird, wie ich bereits im oberen Absatz erwähnt habe, auch der DNS per RA verteilt! Und auch über DHCPv6... kann es also sein, dass Dein PiHole durch den "Rückbau" gerade selbst ohne DNS dasteht? Kann zwar im Prinzip nicht sein, aber sicher ist sicher. Hast Du mal auf der Shell des PiHole, da wo Du auch "pihole -up" eingibst mal versucht dig txt versions.pi-hole.net einzugeben, also so wie es der PiHole in der Meldung auch sagt?! Kommt da eine sinnvolle DNS-Antwort?


Ansonsten war es ggf. nur ein DNS-Schluckauf? Oder ist dieser Fehler der Versionsprüfung reproduzierbar?

 

[Barungar]

@DeathAndPain Ich habe Dein Phänomen auch nochmal kurz gegoogelt.

https://github.com/pi-hole/pi-hole/issues/4722

Aus dem Thread geht auch mehr oder weniger hervor, dass der betreffende User ein DNS-Problem auf seinem PiHole hat(te).
Es mag kurios anmuten, aber für das Updaten, Installieren, usw. verlässt sich PiHole nicht auf sich selbst, sondern greift auf die DNS-Konfiguration des darunter liegenden OS zurück. In diesem Fall also die DNS-Konfiguration des Raspberry selbst.

Kannst Du mal sagen, wie das DNS Deines Raspberry konfiguriert ist?

Die Lösung für den User war dann übrigens, in der /etc/resolve.conf einen "public well-known DNS" einzutragen...

So oder so, würde es darauf hindeuten, dass abseits der PiHole-DNS-Dienste selbst, das "nicht PiHole DNS" in Deinem Netzwerk nicht ganz sauber zu sein scheint.

 

[DeathAndPain]

Ist (meiner Auffassung nach) im IPv6-Betrieb nicht so die gute Idee.

Das war ja auch nur ein aus der Not geborener Move, weil ich gesagt habe, die Fritzbox verteilt ihre LLA, aber auf der reagiert sie anscheinend nicht zuverlässig auf Pings, also muss ich ihr die Verteilung wegnehmen und einem Server übertragen, der stattdessen die (zuverlässig funktionierende) ULA der Fritzbox verteilt. Und dafür hat sich das Pi Hole halt angeboten.

Aber wie Du richtig erkannt hast, ist dieser Ansatz per se gar nicht möglich, da bei IPv6 der Standardgateway nicht vom DHCPv6-Server, sondern vom RA verteilt wird und ein RA nur auf sich selbst als Standardgateway verweisen kann. Deshalb konnte mein Versuch nicht klappen. Mein Rückbau war also nichts anderes, als dass ich den alten Zustand, in dem die Fritzbox DHCPv6 und RA gemacht hat, wiederhergestellt und auf dem Pi Hole die Module für DHCPv6-Server und RA-Server wieder entfernt habe. Das Entfernen des RA-Hakens aus der Konfiguration des Pi Holes hat das ursprüngliche Problem gelöst, denn damit wurde im Netz nur noch die LLA der Fritzbox propagiert, und auf die reagiert sie offenbar zuverlässig (jedenfalls wenn man clientseitig das Interface korrekt mit angibt).

kann es also sein, dass Dein PiHole durch den "Rückbau" gerade selbst ohne DNS dasteht?

Nein, denn im Pi Hole habe ich die Fritzbox als DNS-Server statisch konfiguriert. Ich will ja nicht das Pi Hole vor Werbung etc. schützen; das muss ja sowieso mit dem Upstream-DNS-Server kommunizieren, sonst kann es seinen Job nicht machen. Wobei die Fritzbox als DNS-Server für das Raspbian hinterlegt und dafür auch gut genug ist, während die Pi Hole-Anwendung DNS.WATCH als Upstream-DNS-Server verwendet angesichts der Tatsache, dass der von meinem Provider bereitgestellte DNS-Server der hierzulande verbreiteten Zensur unterliegt.