Beiträge von ::1

DaSokas : Ich möchte nochmals auf folgende Passage eingehen:

Zitat von ::1

Ein erhaltenes RA enthält als Option ja auch die zur (linklokalen) DG-Gateway-Adresse gehörende MAC-Adresse - sie sollte daher auf diesem Wege auch im Neighbor-Cache des WAN-Ports deiner Palo landen. Allerdings wird sie nach Ablauf der maximalen Cachedauer dort gelöscht. Schlecht, wenn die Cachedauer < mittlere Zeitdauer zwischen dem Erhalt zweier RA ist. Kannst du evtl. die Cachezeit des Neighbor-Caches hochdrehen? Z.B. auf die Router-Lifetime (siehe im RA, default: 1800s). Aber das wäre auch nur ein Workaround, nur etwas besser als ein statischer Eintrag im Neighbor-Cache.

In dem Packet Capture sendet das DG-Gateway RA mit folgendem Inhalt:

• Quell-Adresse (=Default-Gateway: fe80::ff:fe04:201)
• Router lifetime: 1800s
• Reachable Time: 0
• Retrans Timer: 0
• Source link-layer address option: 02:00:00:04:02:01

Chapter 6.3.4 in RFC4861 informiert:

6.3.4.  Processing Received Router Advertisements
   
   ...
   
   After extracting information from the fixed part of the Router
   Advertisement message, the advertisement is scanned for valid
   options.  If the advertisement contains a Source Link-Layer Address
   option, the link-layer address SHOULD be recorded in the Neighbor
   Cache entry for the router (creating an entry if necessary) and the
   IsRouter flag in the Neighbor Cache entry MUST be set to TRUE.
   
   ...
   
   If a Neighbor Cache entry is created
   for the router, its reachability state MUST be set to STALE as
   specified in Section 7.3.3.  If a cache entry already exists and is
   updated with a different link-layer address, the reachability state
   MUST also be set to STALE.
   
   ...

Aus Quelladresse fe80::ff:fe04:201 und Link-layer-Adresse 02:00:00:04:02:01 sollte ("SHOULD") deine Palo also tatsächlich einen Neighbor-Cache-Eintrag generieren (wenn auch im Status "STALE"), wobei wegen "Reachable Time" = 0 lokale Voreinstellungen der Palo für die Cache-Dauer gelten.

Falls also tatsächlich ein Eintrag generiert wird (wird er?) und du die Cache-Dauer manuell auf signifikant > 1800/3=600s (mittlere Dauer zwischen zwei RA) einstellen kannst, müsstest du den Cache-Eintrag dauerhaft halten, mithin einen statischen Eintrag vermeiden können.

Andererseits: Die MAC-Adresse 02:00:00:04:02:01 ist ja wegen der eingefärbten 2 keine global gültige, sondern administrativ generiert. Diese und die daraus nach "modified EUI64" abgeleitete Gateway-Adresse fe80::ff:fe04:201 ändern sich nach Beobachtungen an meinem Anschluss niemals (aber man soll ja nie "nie" sagen...).

Zitat von DaSokas

zumindest mit meiner Schlussfolgerung, dass der Fehler wahrscheinlich nicht bei mir liegt,

Das würde ich auch so sehen. Aber ja, lieber einmal mehr hinschauen, um diese Wahrscheinlichkeit zu erhöhen.

Zitat von DaSokas

Ich habe aber gerade gesehen, dass die Palo sehr früh zwei NA vom DG Gateway erhält, die von der Firewall gedroppt werden. Ich vermute mal, dass das passiert, weil die Palo noch keinen ND gestartet hat und daher keine NA erwartet.

Ich denke mal, die Antwort liefert der erste Absatz von Chapter 7.2.5 in RFC4861:

7.2.5.  Receipt of Neighbor Advertisements
   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target.

Ich kann in deinem Packet Capture ansonsten keine Auffälligkeiten erkennen. Es bestätigt lediglich erneut, dass die DG-Gegenstelle keine (solicited) NA auf die sekündlich von der Palo gesendeten NS zurück schickt.

Zitat von DaSokas

Bei meinen Analysen ist mir aufgefallen, dass das Gateway der DG nicht auf Neighbor Solicitation Nachrichten reagiert und damit das DG Gateway nicht in die Neighbor Table aufgenommen wird.

Das ist ein wirklich guter Hinweis, der auch die anderen ähnlich gelagerten Problemfälle erklären könnte!

Das heißt: In deinen Paketmitschnitten an der Palo siehst du:

1. Solicited und unsolicited RA werden von der DG-Gegenstelle gesendet und kommen bei der Palo an?
2. Von der Palo gesendete NS werden hingegen von der DG-Gegenstelle nicht mit NA beantwortet?

Ein erhaltenes RA enthält als Option ja auch die zur (linklokalen) DG-Gateway-Adresse gehörende MAC-Adresse - sie sollte daher auf diesem Wege auch im Neighbor-Cache des WAN-Ports deiner Palo landen. Allerdings wird sie nach Ablauf der maximalen Cachedauer dort gelöscht. Schlecht, wenn die Cachedauer < mittlere Zeitdauer zwischen dem Erhalt zweier RA ist. Kannst du evtl. die Cachezeit des Neighbor-Caches hochdrehen? Z.B. auf die Router-Lifetime (siehe im RA, default: 1800s). Aber das wäre auch nur ein Workaround, nur etwas besser als ein statischer Eintrag im Neighbor-Cache.

Noch ein anderer Gedanke: ND-Pakete sind ja Pakete, bei denen ein Netzinterface selbst Quelle bzw. Ziel des Pakets ist. Bei einer Firewall (und so kenne ich es von einer Cisco ASA, weiß nicht wie es bei einer Palo ist) muss man daher ND-Pakete nicht als übliche FW-Passthrough-Regeln definieren, sondern durch einen gesonderten Satz interface-spezifischer host-based Regeln. Falls das bei einer Palo auch so geregelt ist, müsstest du mal kontrollieren, welche Regeln dort konfiguriert sind.

Ein gewichtiges Argument pro DG-Mietrouter ist ja, dass der (laut dieser Anleitung) bezüglich der Internet-Anbindung (und somit Bereitstellung von IPv4 und IPv6) zentral seitens DG konfiguriert wird.

Wenn also IPv6 nicht funktioniert, obliegt es nicht dem Kunden, dies gegenüber DG nachzuweisen und sogar noch mögliche Ursachenforschung in der DG-Infrastruktur zu betreiben (vermutlich fehlt im BNG eine IPv6-"Rückwärts-Route" zum /56-Block des Kunden über die betreffende WAN-Leitung zum Kunden-Router). Anders als beim "kundeneigenen Router" kann DG sich hier auch nicht damit herausreden, der Kunde habe seinen Router fehlkonfiguriert, denn dessen Konfiguration erfolgt ja seitens DG.

Ich würde DG freundlich auf diesen Sachverhalt in einem Ticket hinweisen, eine Gutschrift für den Zeitraum ohne IPv6 einfordern und zusätzlich eine angemessene Frist zur Problembeseitigung setzen - das Androhen einer Vertragskündigung als Ultima Ratio verleiht der Sache vielleicht auch etwas Druck.

Zitat von ::1

Einen Versuch wäre es wert - hier kannst du eine für eine Mindestlaufzeit mieten;

Es bleibt natürlich anzumerken, dass man eben nicht mal kurz den DG-Mietrouter abklemmt, um stattdessen eine eigene Fritzbox zu testen - dazu müsste DG-seitig ja auch auf das Anschlussprofil "kundeneigener Router" umgestellt werden. Temporär zu Testzwecken wird man das dort wohl nicht tun.

Zitat von idb

Würde eine Fritz mein Problem lösen?

Einen Versuch wäre es wert - hier kannst du eine für eine Mindestlaufzeit mieten; habe ich seinerzeit bei meinem Wechsel vom Telekom-VDSL-Anschluss zu DG auch gemacht.

Noch was: Mich wundert ein wenig die IPv6-Konfiguration des Routers:

Besondere Vorwahl: 2a00:6020:4628:700::/56

WAN IPv6-Adresse: 2a00:6020:1000:42::xxxx (xxxx vermutlich 2880)

Diese Werte werden ja eigentlich per DHCPv6 dynamisch zugeordnet - insofern würde ich hier nichts statisch Konfiguriertes erwarten !?

Nachtrag: Aber vermutlich sind "grau hinterlegte" Felder bei dem Router eh nicht konfigurierbar, sondern zeigen nur die aktuell zugewiesenen Werte an?

Alles so, wie es sein sollte (mit deinem englischen System) - der Wurm steckt woanders.

... sieht bisher alles mustergültig aus.

Aber wg. ULA und korrekter Quelladressauswahl bitte auch noch dieses:

netsh int ipv6 sh pref

Zeig bitte mal die Ausgabe von

netsh int ipv6 sh route

Just for Info: Diese RIPE-Atlas-Probe liegt auch im "Nuernberg-BNG-Cluster1" - IPv6 funktioniert dort einwandfrei. Ist also zumindest keine generelles Problem dieses BNG-Clusters

Zitat von idb

Was genau wird aus der ipconfig /all gebraucht?

Ich würde gerne sehen, welches IPv6-Standardgateway und welche IPv6-DNS-Server eingestellt sind.

Nachtrag: Und es sollte da natürlich (mindestens) eine IPv6-Adresse aus 2a00:6020:4628:700::/56 anliegen

Hi und welcome!

zeig doch mal eine paar (Test-)Ergebnisse, z.B. in einer Eingabeaufforderung an einem Windows-Rechner in deinem LAN, so du einen hast:

• nslookup www.google.com 2a00:6020:100::1
• ipconfig /all

Ein statisch formuliertes FW-Regelwerk auf Basis von IPv6-Adressen ist nun mal per se nicht mit dynamisch zugeordneten Adressen vereinbar. Manche FW unterstützen FQDNs statt IP/IPv6-Adressen, die sie dann per DNS auflösen. Da ist allerdings die Cache-Dauer des Auflösungsergebnisses kritisch zu sehen, denn falls sich die IP/IPv6-Adresse während der Cache-Dauer ändert, ist die aktuelle FW-Regel "falsch" mit entsprechend negativen Auswirkungen.

Eine Fritzbox trickst hier bei der Formulierung von Inbound-Rules (Internet->LAN), indem man den Ziel-Server im LAN nur anhand seines statischen Host-Identifiers (per EUI64 aus dessen MAC-Adresse gebildet) auswählen kann, und die Box den jeweils gerade aktuelle LAN-Präfix "hinzu montiert". Das ist schon recht clever gemacht von AVM.

Zitat von frank_m

Man kann Router so konfigurieren, dass sie solche ICMP Nachrichten nicht schicken.

Aber ein "ICMPv6 Echo Reply" schickte er bei Direktansprache der WAN-Portadresse schon ...

Nachtrag :

Es handelt sich um eine Fritzbox. Dort kann man allenfalls den sog. "Stealth Mode" aktivieren, um das Senden von ICMP- und ICMPv6-Error-Messages zu unterdrücken. In diesem Fall würde sie allerdings auch keine ICMPv6-Echo-Replies senden, was sie aber tat, wie der Traceroute zur WAN-Port-Adresse zeigt.

Zitat von Zaphod

Also bei mir klappt es auch noch nicht.

Dein PD-Block 2a00:6020:76c1:1800::/56 liegt im Range 2a00:6020:7680::/41.

Die PD-Blöcke in den anderen Problemfällen, die nun gelöst zu sein scheinen, liegen jedoch in 2a00:6020:7380::/41.

Zitat von Taxan4711

sorry, falsches Paste, PD ist 2A00:6020:4722:7A00::/56

Für den Range müsstest du am BNG 2a00:6020:ffff:ffff::23 hängen und die WAN-Portadresse 2a00:6020:1000:44::226a haben (nach der Regel, die ich hier beschrieben habe), liege ich da richtig? Diese WAN-Portadresse erreicht man mit einem Traceroute:

Ein Traceroute für die Dummy-Adresse ::3 in deinem PD-Block zeigt hingegen dies:

Hier hätte ich als Hop 14 ein "ICMPv6: Destination unreachable" von deiner WAN-Portadresse 2a00:6020:1000:44::226a erwartet.

Das könnte tatsächlich darauf hindeuten, dass der BNG keine Route für deinen PD-Block 2a00:6020:4722:7a00::/56 besitzt. Dieser BNG bedient den Range 2a00:6020:4700::/40 im Raum Nürnberg, zumindest laut RIPE-netname="Nuernberg-BNG-Cluster2".

Für den gab es vom 04.02.2025 bis 06.02.2025 eine IPv6-Störung. Ich hänge mit meinem Anschluss auch an diesem BNG, IPv6 habe ich seit Störungsende auch wieder zur Verfügung.

Aber vielleicht ist da ja noch nicht alles behoben ...

Nachtrag:

Mit den anderen hier im Forum diskutierten IPv6-Problemen im Range 2a00:6020:7000::/36 hat dein Fall allerdings nichts zu tun, denn dein Anschluss liegt im Range 2a00:6020:4000::/36.

Zitat von ConiKost

Die Probleme wären gelöst, wenn man endlich flächendeckend IPv6 ausgerollt hätte

Zitat von pufferueberlauf

Das geht halt nur Schritt fuer Schritt, ISP fuer ISP...

Das Problem hierbei sind nicht die ISPs - die sind damit eigentlich schon fertig. Die müssen eben "noch" IPv4 in Form von CGNAT-Krücken anbieten.

Das Problem sind die Enterprises, Behörden, bzw. allgemein die Institutionen, die Services im Internet bereitstellen - da sträubt sich die Mehrheit der Netz-Admins, in deren jeweils zugrunde liegenden Netzinfrastrukturen IPv6 einzuführen. Die meiden das, wie der Teufel das Weihwasser...

Bestes Beispiel: Dieses Forum ist noch immer nicht über IPv6 zu erreichen.

Hierzu ein unterhaltsamer Link. Und der hier ist auch nicht zu verachten.

Immerhin kommst du zu dem BNG (2a00:6020:ffff:ffff::23), an dem dein Anschluss hängt. Der nächste Hop wäre die WAN-Port-Adresse deines Routers (2a00:6020:1000:...).

Es könnte daran liegen, dass DG-seitig eine (aus DG-Sicht) Outbound-Route im BNG zu dem /56-PD-Block deines LAN-Bereichs fehlt.

Kann aber auch immer noch an deinem Router liegen ...