Beiträge von ::1

Mir ist nicht so ganz klar, welche Art von Internetzugang du mit Novanetz du nun hast. Entsprechen die Screenshots in #6 denn der aktuellen Einstellung deiner Fritzbox? Falls ja, dann hast du einen sog. DS-Lite-Anschluss. Das bedeutet: Dein Router bekommt an seinem WAN-Port gar keine IPv4-Adresse mehr, sondern nur noch eine IPv6-Adresse. Dein LAN bekommt ein sog. IPv6-Präfix, aus dem sich die Endgeräte per Autokonfiguration selbst jeweils eine (öffentliche!) IPv6-Adresse generieren. IPv4-Pakete Richtung Internet werden nun von der Fritzbox über IPv6 "getunnelt", d.h. der Inhalt eines IPv6-Pakets ist ein vollständigen IPv4-Paket. Das wird dann beim Provider aus dem Tunnel "ausgepackt" und über einen zentralen NAT-Router beim ISP (CGNAT) nach dortiger Übersetzung deiner privaten IPv4-Quelladresse in eine öffentliche ins Internet gesendet.

Der Fritzbox-DynDNS-Client kann bei Selfhost folglich gar keine IPv4-Adresse mehr registrieren, weil du gar keine mehr hast. Er kann nach entsptrechender Anpassung nur noch die IPv6-Adresse am WAN-Port deiner Fritzbox registieren. Das würde ja passen, wenn du im Anschluss dorthin eine VPN-Verbindung via Wireguard konfigurieren möchtest.

Falls du MyFritz nutzt, brauchst Du Selfhost wiederum nicht mehr, weil MyFritz ja eine alternative DnyDNS-Lösung darstellt, die zudem auch noch die stellvertrendende Registrierung von Endgeräten (z.B. deine Synology) übernehmen könnte.

Aber nur zeige doch erst Mal, dass in deinem Netz IPv4 und IPv6 sauber funktionieren: Poste bitte mal die Ausgabe folgender Kommandos in einer Eingabeaufforderung an einem Windows-Rechner (ich gehe davon aus, dass du einen hast):

• ping -4 www.google.com
• ping -6 www.google.com

Dann zeige bitte mal folgende Screenshots deiner Fritzbox, wobei du gerne die Ziffern 9-16 (von links gezählt, also die zwischen dem zweiten und vierten ":") in deinen IPv6-Adressen schwärzen kannst:

• Internet | Online-Monitor | Verbindungsdetails
• Heimnetz | Netzwerk | Netzwerkeinstellungen | IPv6-Einstellungen | Verwendete IPv6 Präfixe (ganz unten auf der Seite)

Zitat von DaSokas

Ich bin sogar so weit gegangen und habe versucht der BNetzA zu erklären, dass man hier durchaus einen Router-Zwang ableiten könnte, da ich dazu gezwungen werde einen Nicht-Standardkonformen Router zu verwenden, wenn ich IPv6 verwenden möchte.

Ich denke, diese Aussage meinst du nur einschränkend für den BNG-Port zu deinem Kundenanschluss, um dessen vermutete Fehlkonfiguration zu kompensieren, also jedenfalls nicht generell?

Ich habe mir mal die Mühe gemacht, neben der allgegenwärtigen Fritzbox andere Router-Modelle an allen IPv6-aktiven DG-Anschlüssen zu identifizieren, die eine RIPE-Atlas Probe betreiben (LINK).

Auf Basis der Eigenbeschreibungen im Datenfeld "Router Type" konnte ich folgende Router-Modelle identifizieren:

• OPNsense: Probe 60646
• OpenBSD: Probe 53717
• MikroTik: Probes 1359, 14149, 28932, 61286, 1006149, 1010188

Ich denke mal, unter diesen drei genannten Router-Modellen wird sich bestimmt mindestens eines befinden, das bzgl. ND standardkonform arbeitet .

Zitat

IPv6 funktioniert, aber nur wenn ich einen defekten Router verwende, den die DG auch ganz zufälligerweise ihren Kunden anbietet.

Oder eher so:

Dein BNG (DG-Gateway) ist bezogen auf deinen Kundenanschluss mindestens dahingehend gestört/fehlkonfiguriert, als dass es die von deiner Palo erhaltenen NS an die zu seiner Gateway-Adresse gehörende SNMA nicht mit NA beantwortet. Diesen Fehler kann zwar eine Fritzbox aufgrund nicht RFC-konformer ND-Implementierung kompensieren, nicht jedoch ein RFC-konform arbeitender Router bzw. Endgerät. Ohne die BNG-Fehlkonfiguration könnte auch deine Palo reibungslos IPv6 nutzen.

Ich könnte mir folgende Ursache am BNG vorstellen:

Für das Interface zu deinem Anschluss hat kein Join zu der Multicast-Gruppe stattgefunden, die der SNMA der link-lokalen IPv6-Adresse des DG-Gateways entspricht. Deswegen nimmt es keine an diese SNMA gerichteten NS an. Das zu überprüfen, wäre mal ein konkreter Hinweis an DG.

Dein BNG gehört wohl zum "Hannover-BNG-Cluster-2", das für deinen Anschluss zuständige BNG müsste die DG-interne Adresse 2a00:6020:ffff:ffff::13 haben.

Zitat von DaSokas

Ich vermute mal, dass du sowas gesucht hast?

Nö, ich suchte nach Informationen zu rein interface-basierten Filterregeln, mit denen man ND-Traffic reglementieren kann. Ganz im Sinne von Chapter 4.4 in RFC4890 bezüglich dessen, was dort als "ICMPv6 Local Configuration Traffic" bezeichnet wird - im Gegensatz zu "ICMPv6 Transit Traffic" im Chapter 4.3 (was ich in einem früheren Post als "Passthrough" bezeichnet hatte).

Aber sowas scheint es bei einer Palo nicht zu geben, wie du ja auch schon gesagt hast.

Zitat von DaSokas

Ich habe auch meine alte FritzBox 7590 angeschlossen und festgestellt, dass es dabei keine Probleme gibt. Ein Packet Capture hat ergeben, dass die FritzBox (anscheinend) nicht Standardkonform arbeitet und aufgrund der eingehenden RA den Router sofort als "erreichbar" markiert.

Ja, wenn ich in die Packet-Captures aus meiner Fritzbox 7590 anschaue, sehe ich folgendes Verhalten:

Bis zum Abschluss der DHCPv6-Transaktionen zum Bezug einer IPv6-Lease (IA_NA, IA_PD) sehe ich keinerlei NS/NA-Kommunikation außer denen, die die Fritzbox für ihre eigenen IPv6-Adressen im Rahmen der DAA (Duplicate Address Detection) sendet.

Die erste NS, die die Fritzbox zur Auflösung der DG-Gateway-Adresse sendet, erfolgt bereits als IPv6-Unicast an eben jene Gateway-Adresse und nicht als IPv6-Multicast an die aus der Gateway-Adresse abgeleitete SNMA (solicited node multicast address). Das deutet darauf hin, dass die Fritzbox die DG-Gateway-Adresse zusammen mit deren MAC-Adresse bereits im Neighbor-Cache hatte (statt state=STALE, offenbar schon als REACHABLE geflagt). Dort hinein kann der Eintrag aber nur durch vorangegangene, erhaltene RA des DG-Gateways gelangt sein. Eine Verwendung von SNMA sehe ich nur für NS, die das DG-Gateway an meine Fritzbox sendet, witzigerweise auf Ethernet-Ebene als Unicast an die MAC meiner Fritzbox und nicht als Ethernet-Multicast an 33:33:xx:xx:xx:xx.

Ach, noch eine Idee: Um die Palo als Ursache wirklich auszuschließen, klemm doch einfach mal einen PC direkt an den Anschluss (aber erst mal 1 Stunde warten!). In deinem Packet Capture dort solltest du dann auch keine NS/NA-Kommunikation sehen, wenn es tatsächlich an DG liegt.

Zitat von DaSokas

Ich stimme der Aussage, dass dort "genügend Raum" sei, allerdings nicht zu.

Dann würde ich die fundierte Problembeschreibung in ein separates Dokument auslagern und dieses als PDF-Attach anhängen.

Zitat von DaSokas

Das TKG macht keine Vorgaben, dass eine Konnektivität via IPv4 oder IPv6 gegeben sein müsse.

Das wäre ja ziemlich sinnfrei!?

Aber ja, das Problem ist herausfordernd, du kannst nur hoffen, bei DG einen last-level-Techie zu finden, der es versteht und in die richtigen Bahnen leiten kann. Und genau das passiert aber leider häufig erst nach Regress- oder Kündigungsandrohungen.

Eine Unsicherheit in der technischen Analyse habe ich noch: Welchen View zeigen deine Captures?

1. Den Traffic, bevor (outbound) eine Firewall-Regel greift, die das Paket dann doch verwirft, und (inbound), nachdem zuvor schon eine Firewall-Regel gegriffen und ein Paket verworfen hat, so dass du es im Capture gar nicht mehr siehst?
2. Den Traffic so, wie er (nach Berücksichtigung von FW-Regeln) outbound die Firewall verlässt, bzw. inbound, bevor eine FW-Regel greift?

Im Fall (1) würdest du genau die Captures sehen, die du durchgeführt hast - tatsächlich hätte deine Firewall aber ausgehend und einkommend NS/NA gedroppt.

Die Palo ist schon ein ziemliches Monster. Die Doku zu PAN-OS wirkt erschlagend - was ich dort suchte, fand ich jedenfalls nicht.

Zitat von DaSokas

Wenn dem wenigstens so wäre, allerdings wurde ein Routing-Problem von Anfang an von der DG ausgeschlossen. Ich wüsste nicht, wie ich das auf meiner Seite überprüfen könnte.

NS/NA-Kommunikation erfolgt ja stets nur link-lokal. Wenn sie also nicht funktioniert, kann das nicht an einem Routing-Problem liegen. Ein solches liegt ja auch nicht vor, denn IPv6 funktioniert problemlos mit dem statischen Neighbor-Cache-Eintrag. (Nachtrag: Entschuldigung, deine Aussage bezog sich ja auf die von mir zitierten fehlgeleiteten NA-Antworten zu anderen Kundenanschlüssen als dem, aus dem das anfordernde NS kam - ja, insofern ein "Fehlrouting", obwohl es streng genommen kein "Routing" ist, sondern ein Konfigurationsfehler des BNG)

Ich würde nochmal ein Packet-Capture von einem DG-Connect, beginnend mit der WAN-Interface-Initialisierung erstellen, das alle relevanten Pakete (Raw-Daten geeignet filtern: icmpv6 || dhcpv6) enthält. Hinweis: Dein gezeigter Packet Capture bestand aus zwei getrennten Traces für beide Richtungen. Diese kannst du in Wireshark wie folgt mergen: Öffne erst eine der beiden Dateien. Wähle dann "Datei | Zusammenführen...". Aktiviere im Dateiauswahl-Dialog die Option "Chronologisch zusammenführen" und wähle anschließend die andere Datei aus. Anschließend den Merge unter separatem Namen speichern.

Wie auch schon mehrfach hier im Forum empfohlen, verwende unbedingt das DG-Kundenportal und mache dort unter "Service | Kontaktformular" ein Ticket auf. Dort hast du genügend Raum, das Problem möglichst präzise zu beschreiben. Füge auch einen Screenshot des Packet Capture bei, das allein ist schon sehr aussagekräftig. Die Capture-Datei solltest du natürlich als Attach mit anhängen. Du kannst ja auch noch gerne deinen Einstiegs-Post in diesem Thread mit verlinken.

Da deine technische Argumentation ziemlich schlüssig ist, kannst du auch etwas tougher auftreten und durchaus Regress-Ansprüche andeuten. Ich habe gelernt, dass bei DG letzteres tatsächlich weiterhelfen kann (leider, ich würde mir das auch anders wünschen).

Zitat von Hotte

Wenn ich allerdings über VPN ins Netz gehe habe ich nur ipv4 und das bei mehreren Servern.

Ruf doch mal wasistmeineip auf, wenn du über VPN ins Netz gehst. Dort wirst du wahrscheinlich nur eine IPv4-Adresse sehen, die nicht dir, sondern dem VPN-Anbieter gehört (deshalb nutzt du ja auch VPN).

Übrigens: In diesem Post zu einem ähnlichen Problem (erhält IPv6-Adressen, kann aber dennoch nicht via IPv6 mit dem Internet kommunizieren) habe ich nach Auswertung eines Packet Capture die folgende Beobachtung festgehalten:

"Die IPv6-Kommunikation beschränkt sich auf den Austausch von ND-Paketen (NS, NA, RA) mit der DG-Gegenstelle (fe80::22). Auch hier auffällig: Du erhältst unzählige Neighbor-Advertisments (NA) als Unicasts an linklokale IPv6-Adressen, die vermutlich nicht zu deinem Anschluss gehören, und die als "solicited reply" geflagt sind, obwohl von deinem Router zuvor keine dazu passenden Neighbor-Solicit (NS) gesendet wurden."

Ich hatte dann mal näher anhand der OUI der Ziel-MAC-Adressen der fehlgeleiteten NA festgestellt, dass sie alle zu AVM bzw. SAGEMCOM (von denen ist der einfachere DG-Mietrouter) gehören.

Vielleicht werden die NA zu den von deiner Palo gesendeten NS ja auch zu anderen Kundenanschlüssen fehlgeleitet ...

Der RFC formuliert diesbezüglich auch nur "SHOULD", nicht "MUST". Wenn die Palo einen Eintrag erzeugt, müsstest du ihn nach Erhalt eines RA sehen.

Noch eine andere Frage:

In deinem Packet Capture habe ich keinerlei NS gesehen, die vom DG-Gateway an die Palo gesendet werden. War das nur in diesem Capture der Fall, oder sieht man auch keine ankommenden NS bei längeren Laufzeiten? Ein NS von der Gegenstelle enthält ja ebenfalls eine "Source link-layer address option", mit der die Palo einen Neighbor-Cache-Eintrag generieren könnte bzw. würde.

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.