Beiträge von DaSokas

Zitat von ::1

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

OPNsense: Probe 60646

Ich habe jetzt meine Palo durch eine (virtuelle) OPNsense ersetzt und musste feststellen, dass die OPNsense keine Probleme mit der IPv6 Konnektivität hat. Ich muss aber gestehen, dass ich (noch) nicht herausgefunden habe, was die OPNsense anders macht als die Palo.

Ich bekomme nun wie erwartet NA Antworten des DG-GW auf NS Anfragen der OPNsense, womit das DG-GW in die ND-Table aufgenommen wird. Das Resultat ist, IPv6 funktioniert.

Da ich momentan sehr wenig Zeit habe, werde ich weitere Untersuchungen irgendwann in der Zukunft durchführen. Mich macht das schon etwas stutzig, was die genauen Unterschiede sind..

Zitat von ::1

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

Ich habe nicht alle Router-Modelle dieser Welt an meinem Anschluss testen können und habe entsprechend auch keine Packet Captures durchgeführt und diese analysiert, entsprechend war diese Unterstellung (bewusst) weit hergeholt.

Es ging darum die DG zu einer Handlung zu zwingen.

Zitat von ::1

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

Genau, Nicht-Standardkonform und mein Hinweis auf den ND Prozess im RFC 4861 hat auch niemanden interessiert, weder die DG noch die BNetzA.

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.

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

Ich zitiere hier mal die BNetzA bzgl. dieser Angelegenheit:

Zitat

Falls Sie [DaSokas] keinen intellektuellen Zugang zu dieser Thematik haben sollten, könnte Ihnen eine Internetrecherche helfen.

Sorry, ich bin gerade innerlich am Kochen..

Zitat von pufferueberlauf

Allerdings vermute ich, dass die DG eigentlich vorhat funktionierendes IPv6 zu liefern und es hier kein Kampf gegen den ISP ist, sondern gegen die Prozesse des ISP die Techniker von Endkunden trennen, denn eigentlich habt ihr das selbe Interesse und IMHO waere es vielleicht hilfreich wenn die DG Technik mit Dir Kontakt aufnaehme, nicht dass meine Meinung da igendetwas aendern koennte...

Ich wurde schon einmal von der Beschwerdeabteilung kontaktiert, allerdings habe ich hier nichts weiter gehört und das dazugehörige Ticket wurde zum Schluss geschlossen, mit dem Hinweis, dass der Anschluss instand gesetzt wurde.

Als ich mit dem guten Herren der Beschwerdeabteilung gesprochen hatte, habe ich auch gesagt, dass mich die Techniker gerne direkt anrufen dürfen, falls sie meine mithilfe benötigen. Ich habe auch explizit darauf hingewiesen, dass ich 24/7 für die DG zur Verfügung stehe, weil mir die Problemlösung eben wichtig ist.

Nun zur Preisfrage: Glaubst du, dass ich von einem Techniker jemals angerufen wurde?

Zitat von pufferueberlauf

Aus eigener Erfahrung mit Problemen bei O2 muss ich sagen, dass manche Loesungen Monate in Anspruch nehmen und Endkunden wie wir meist nicht/kaum mit Zustandsupdates versorgt werden. Ich hoffe mal die Techniker der DG arbeiten still und heimlich an einer Loesung.

Das wäre ja auch vollkommen okay, wenn ich nicht immer per E-Mail darüber informiert werden würde, dass es keine Probleme gäbe und die Tickets geschlossen werden. Ich muss dann explizit ein neues Ticket mit einer "Rückfrage" zum geschlossenen Ticket eröffnen.

Zitat von ::1

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.

Das hatte ich noch letztes Jahr im Dezember gemacht, damit ich die Palo ausschließen kann. Auch mein Desktop (Windows 11 Pro) erhält zwar eine IPv6 hat aber keine Konnektivität. Ein Packet Capture hat ergeben, dass die DG nicht auf NS Nachrichten reagiert.

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.

Zitat von ::1

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

Das ist eine berechtigte Frage.

Die Palo kann Pakete in vier Stages aufzeichnen:

• Receive (zeichnet alle erhaltenen Pakete auf)
• Transmit (zeichnet alle gesendeten Pakete auf)
• Firewall (zeichnet alle von der Firewall zu verarbeitenden Pakete auf)
• Drop (zeichnet alle gedroppten Pakete auf)

Den Packet Capture selbst kann man dann noch mit insgesamt vier Filter-Regeln eingrenzen.

Ich habe meine Packet Captures grundsätzlich so konfiguriert, dass ich alle IPv6 Pakete am WAN Interface für alle vier Stages aufzeichne. Wenn keine Pakete in einer Stage aufgezeichnet werden, dann erstellt die Palo auch keine Datei.

Alle meine Packet Captures benenne ich entsprechend ihrer Stage und schicke alle erstellten Dateien an die DG, damit den Technikern keine Informationen fehlen.

Zitat von ::1

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

Ich vermute mal, dass du sowas gesucht hast?

(Das ist noch das alte Interface von PAN-OS. Die GUI sieht inzwischen etwas anders aus, aber die Quintessenz ist die Gleiche)

Zitat von pufferueberlauf

Dabei ist der Umstand eigentlich relativ einfach:

es gibt Bereiche des INternets die nicht per IPv4 erreicht werden koennen

es gibt Bereiche des Internet die nicht per IPv6 errreicht werden koennen.

Daher sollte es selbstverstaendlichn sein, dass ein ISP dafuer sorgt, dass alle Bereiche des Internets fuer siene Kunden erreichbar sind.

Der Meinung bin ich auch, allerdings habe ich in meiner jetzigen Position keine weiteren Möglichkeiten eine Problemlösung zu erzwingen.

Da ich hier in einem relativ kleinen Dorf wohne habe ich auch keine wirklichen alternativen zur DG, da diese hier nicht existieren. Die DG ist leider der einzige Glasfaser-Anbieter, alternativ könnte ich bei der Telekom einen DSL Tarif buchen bis maximal 175 MBit/s. Dafür würde ich dann monatlich "nur" 5,00€ mehr bezahlen, allerdings weniger als die Hälfte meiner jetzigen Bandbreite erhalten..

Zitat von ::1

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.

Das habe ich nicht ganz klar kommuniziert, genau darum beanstande ich es auch nicht.

Zitat von ::1

Ich würde nochmal ein Packet-Capture von einem DG-Connect, beginnend mit der WAN-Interface-Initialisierung erstellen, das alle relevanten Paket (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.

Das habe ich die letzten vier Tickets schon gemacht, der einzige Unterschied zwischen deinem Vorschlag und dem was ich gemacht habe ist, dass ich keine Filter für ICMPv6 und DHCPv6 erstellt habe.

Zur Erklärung: Ich führe alle meine Tests ausschließlich auf der Palo durch. Solange ich nicht sicher bin, dass das Problem seitens der DG nicht behoben ist, möchte ich kein IPv6 Prefix in meinem Netzwerk bekannt geben, damit ich wenigstens keine Timeouts habe.

Zitat von ::1

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.

Genau so eröffne ich meine Tickets. Ich stimme der Aussage, dass dort "genügend Raum" sei, allerdings nicht zu. Die Zeichengrenze liegt bei 2,000 Zeichen, was zwar viel klingen mag, aber für eine technische Problemschilderung unzureichend ist.

Zitat von ::1

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).

Der Teil interessiert mich, besonders weil ich die BNetzA eingeschaltet hatte und man mich dort, nachdem man mir unterstellt hat, dass ich keine Ahnung von der Materie hätte, darüber informiert, dass es keine gesetzliche Grundlage für diesen Fall gäbe.

Ich habe eine funktionierende Internetverbindung, damit sei der Internetzugang im Sinne des TKG nicht gestört. Das TKG macht keine Vorgaben, dass eine Konnektivität via IPv4 oder IPv6 gegeben sein müsse. Damit weigert sich die BNetzA diesen Fall zu bearbeiten.

Zitat von ::1

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?

Da ich das selbst nicht mehr im Kopf hatte, habe ich einen längeren Packet Capture durchgeführt. Die Palo erhält keine NS Nachrichten, weder vom DG Gateway, noch von anderen Routern.

Zitat von ::1

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

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.

Noch ein Update: Ich habe eine weitere Antwort von der DG erhalten, dass das Problem auf meiner Seite liegen würde und ich bitte mit dem Hersteller der Firewall in Kontakt treten soll, da dieser - und ich zitiere - "da dieser direkten Zugriff auf das Gerät hat und Ihnen gezielt bei der Fehlerbehebung weiterhelfen kann.".

Ich habe jetzt erneut eine Rückfrage gestellt, wie die Techniker zu dem Entschluss gekommen sind, dass das Problem bei mir liegen würde, in der Hoffnung, dass die "Techniker" konkret erklären, was das Problem ist..

Zitat von ::1

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.

Der Standard-Wert für die Reachable Time der Palo beträgt 30s. Ich habe die Reachable Time manuell auf 1800s gestellt um sicherzustellen, dass ich nicht zu langsam bin und den Eintrag in der ND-Table einfach verpasst habe. Die Palo erstellt anscheinend keinen Eintrag in der ND-Table.

Zitat von ::1

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.

So blöd das auch klingen mag, freut mich das zu hören. Dann scheine ich, auch wenn ich einige Details zum RFC4861 nicht mehr korrekt im Kopf hatte, zumindest mit meiner Schlussfolgerung, dass der Fehler wahrscheinlich nicht bei mir liegt, nicht ganz falsch zu liegen.

Vielen Dank!

Ich habe die IPv6 Konfiguration gerade entfernt und nochmal neu erstellt, damit ich für diejenigen, die Interesse haben, einen Packet Capture bereitstellen kann.

Der Packet Capture ist auf jeglichen IPv6 traffic des WAN Interface beschränkt, weshalb der Ping vom LAN Interface auf die Google DNS Server (2001:4860:4860::8888) nicht zu sehen ist.

Zitat von ::1

Solicited und unsolicited RA werden von der DG-Gegenstelle gesendet und kommen bei der Palo an?

Ich sehe im Packet Capture lediglich unsolicited RA.

Zitat von ::1

Von der Palo gesendete NS werden hingegen von der DG-Gegenstelle nicht mit NA beantwortet?

Genau.

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..

Alle späteren NS von meiner Palo werden vom DG Gateway nicht mehr beantwortet.

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.

Ich möchte mich nicht zu weit aus dem Fenster lehnen, aber warum sollte der RA dazu führen, dass ein Eintrag im ND erstellt wird? Wenn ich den RFC 4861 richtig im Kopf habe, dann sind die RAs doch lediglich dafür da (salopp gesprochen) einen Router bekannt zu geben und dafür zu sorgen, dass Hosts sich eine IP generieren können.

Mal ein theoretisches Konstrukt: Ich könnte einen Router A nutzen um eine Route via Router B bekannt zu geben. Nur durch den RA weiß der Host aber nicht, ob Router B tatsächlich erreichbar ist, weshalb der Host per ND prüft, ob Router B tatsächlich erreichbar ist. Erst wenn sichergestellt ist, dass Router B existiert, wird der Eintrag der ND-Table hinzugefügt, oder nicht?

Edit: Ignorier den Schwachsinn von oben bitte, ich habe mir gerade nochmal RFC 4861 angeschaut und gesehen, dass ein RA die zwei Felder "Reachable Time" und "Retrans Timer" besitzt, mit denen konfiguriert werden kann wie lange der Router in der ND-Table als erreichbar markiert bzw. wann erneut NS versendet werden sollen.

Zitat von ::1

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.

Gute Idee, allerdings wäre mir das neu, dass man das bei der Palo explizit konfigurieren muss. Ich habe auch vor meiner Analyse im Dezember (bitte keine Steine werfen) kein Update meiner Palo durchgeführt.

Hallo zusammen,

ich habe mich heute aufgrund meines Frustes mit der DG hier im Forum registriert und habe dasselbe "Phänomen", dass ich zwar eine IPv6 erhalte, allerdings keine Konnektivität habe.

Ich nutze eine Palo Alto PA-440 als Router. Ich hatte bis letztes Jahr Oktober keine Probleme mit meiner IPv6 Konnektivität. Irgendwann um diese Zeit ist mir dann aufgefallen, dass viele Websites (u.a. Google) in einen Timeout laufen. Nachdem ich die Websites (nach dem Timeout) aktualisiert habe, waren sie erreichbar. Niemand sonst hatte Probleme.. komisch.

Da ich aufgrund meiner Arbeit nur wenig Zeit hatte, habe ich mich mit dem Problem abgefunden und das Problem erst im Dezember begonnen zu analysieren.

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 hat zur Folge, dass ich zwar eine IPv6 erhalte und eine Default-Route in die Routing Table aufgenommen wird, da allerdings das DG Gateway aus der Sicht der Firewall nicht existiert, werden auch keine Pakete an dieses weitergeleitet.

Das Einzige, was ich bei meiner PA-440 als Workaround machen kann, ist einen statischen Eintrag in die Neighbor Table hinzuzufügen (das geht natürlich nur so lange gut, wie sich die IP Adresse des DG Gateways nicht ändert).

Vielleicht hilft dir/euch diese Information?

Ergänzend: Ich bin seit Januar mit der DG am kämpfen, dass dieses Problem behoben wird, allerdings sind die höchstqualifizierten Techniker der DG der Meinung, dass kein Problem bestehen würde und schließen seither meine Tickets, ungeachtet der Packet Captures, die ganz klar das Gegenteil beweisen..