Beiträge von ::1

Zitat von Xaver

Guten Tag, meine Fritzbox kann keine Verbindung mit dem Internet aufbauen. Beim Versuch das Problem zu lösen bin ich auf diese super Anleitung gestoßen. Leider komme ich nur bis zum Punkt "neu verbinden". Unser neuer Ersatzrouter war noch nie mit dem Internet verbunden und zeigt mir die Möglichkeit "neu verbinden" nicht an. Gibt es da einen Trick bzw. eine anderen Möglichkeit Paketmitschnitte anzufertigen?

Deine Intention ist sicherlich, herauszufinden, was am WAN-Port der neuen FB passiert, während sie versucht, eine Internetverbindung zum ISP herzustellen. In meiner Anleitung möchte ich diese Verbindungsaufbauphase provozieren, indem ich ein "Neu verbinden" auslöse. Das ist für deinen Fall aber gar nicht erforderlich, denn deine Box steckt doch sowieso schon in dieser Phase (fest). Insofern brauchst du nur einen Paketmitschnitt eine Weile laufen zu lassen (den 5. Punkt der Anleitung einfach überspringen), um zu sehen, was am WAN-Port passiert.

Btw.: Wer ist dein ISP? Falls es DG ist: Hast du nach Abklemmen das alten Routers mindestens eine Stunde gewartet, bevor du den neuen Router angeschlossen hast?

Zitat von Schlammdackel

Und zwar nur, weil ich die VLAN ID von 360 auf 362 änderte !

Siehe auch hier (20.10.2025): https://administrator.de/forum/fritzbox…ung-675109.html

Dort musste allerdings genau anders herum von VLAN 362 auf VLAN 360 gewechselt werden

Zitat von Schlammdackel

Ich habs gefunden:

2a00:6020:409b..........

Ok, das ist der BNG-Cluster, der für Kundenanschlüsse im IPv6-Bereich 2a00:6020:4080::/41 zuständig ist (In Traceroutes aus dem Internet zu Zielen in diesem Block mit der Adresse 2a00:6020:ffff:ffff::1a). Da findet man bei RIPE-Atlas leider keine aktiven Probes, sondern nur diese vier im Status "Abandoned": 21385, 22985, 26828, 28346. Insofern sind wir jetzt leider nicht schlauer.

Schau mal in die Ereignisanzeige deiner FB - Tab "Internetverbindung" und scrolle ganz nach unten. Wenn du Glück hast, steht die letzte LAN-Adresse (2a00:6020:XXXX:YY00/56) da noch drin.

Kannst du mir für die IPv6-LAN-Adresse, die du zuletzt zugewiesen bekommen hast, die drei Ziffern XXX aus 2a00:6020:XXX verraten? Daran könnte ich erkennen, an welchem BNG der DG dein Anschluss hängt. Ggf. könnte man dann RIPE-Atlas-Probes finden, die ebenfalls an diesem BNG hängen und schauen, ob die auch Verbindungsprobleme haben.

Zitat von Schlammdackel

Ticket ist schon aufgemacht, sind jetzt schon 6 Tage ohne Netz

Das ist in der Tat zu lang - kam an meinem DG-Anschluss bisher maximal für 5 Stunden vor und betraf abwechselnd IPv4 oder IPv6, aber niemals beide Protokolle gleichzeitig.

Die DG-Störungsseite zeigt keine Störungen an.

Das bestätigt das Bild:

Layer 2 (Glasfaser): OK
Layer 3 (IP/IPv6): ERROR (Der DHCP-Server der DG mag dir keine Adressen zuweisen, betrifft sowohl IP als auch IPv6)

Musst du ein Ticket bei DG aufmachen.

Oder einfach abwarten, löst sich nach einiger Zeil von selbst ...

Schau doch mal in die Ereignisanzeige deiner FBox. Die ist wahrscheinlich voller DHCP- bzw. DHCPv6-Fehlermeldungen, weil DG keine IPv4- bzw. IPv6-Adressen zuweist.

Zitat von kostolany25

Ich werde verrückt! Im Destination-Cache tauchen beide IP-Adressen nicht auf 🤬

sind wahrscheinlich nach Timeout verschwunden.

Ist auch nicht so wichtig - wäre nur eine Bestätigung, dass Path-MTU-Discovery für IPv4 bzw. IPv6 funktioniert, und die LAN-Geräte die verkürzten MTU-Werte des Routers als PMTU für Internetziele (1452 für IPv4 und 1492 für IPv6) anstelle der üblichen 1500 lernen.

Zitat von kostolany25

Bei IPv4 funktioniert es nur mit 1424, bei allen anderen Größen kommt der Hinweis auf die Fragmentierung.

bei IPv6 funktioniert es nur mit 1444, bei den anderen Größen kommt die Meldung „Allgemeiner Fehler“.

So habe ich es erwartet.

Kannst du nach einem Ping für IPv4 bzw. IPv6 auch mal in den IPv4- bzw. IPv6-Destination-Cache des pingenden Rechners nach den Einträgen für die jeweils aufgelöste IPv4- bzw. IPv6-Adresse des Ping-Ziels (google.com?) schauen, ob für diese als Path-MTU (PMTU) jeweils 1452 bzw. 1492 eingetragen ist?

If so: Dann ist alles gut, und wir brauchen nicht weiter das MTU-Thema zu reiten.

Nachtrag:

Bedeutet somit auch, dass purtel.com keine Jumbo-Frames für die WAN-Strecke verwendet.

kostolany25 : Noch ein Nachtrag zu #159:

Du scheinst im LAN eine falsch konfigurierte IP-Route für das Zielnetz 192.168.178.0/24 (Standard LAN-Adresse einer AVM-Fritzbox) zu haben, die dazu führt, dass Pakete zu Zieladressen in diesem Netzbereich über die DS-Lite-Verbindung zum Internet (also getunnelt zum AFTR) gesendet werden.

Man sieht (wiederholt) TCP-SYN-Pakete zum Aufbau von TCP-Verbindungen zu folgenden Adressen:Ports ...

192.168.178.1:49000
192.168.178.39:5001
192.168.178.39:8443
192.168.178.64:80
192.168.178.61:80
192.168.178.55:80
192.168.178.76:2001
192.168.178.76:8701
192.168.178.193:8000

... und zahlreiche Retransmits dieser SYN-Pakete, auf die natürlich niemand antworten kann:

Das Gute ist aber, dass diese TCP-SYN-Pakete sämtlich die MSS-Option (Maximum Segment Size) = 1412 enthalten:

Eine TCP-Segment der maximalen Größe von MSS=1412 Bytes ergibt zusammen mit einem TCP-Header (20 Bytes) und einem IP-Header (20 Bytes) ein IP-Paket der Länge 1452 Bytes. Und das ist genau die MTU des 4-in-6-Tunnel-Interface für DS-Lite over PPPoE.

Welcher LAN-Client diese Irrläufer auch immer gesendet hat: Er hat also per Path-MTU-Discovery offenbar schon die Längenbegrenzung von IPv4-Paketen auf maximal 1452 Bytes gelernt.

Um bzgl. MTU mal ein wenig herumzuspielen bzw. die Limits zu testen, kann man an einem LAN-PC gezielt PING-Pakete mit konfigurierbaren Paketgrößen generieren, um so herauszufinden, welche maximalen Paketgrößen zu ausgewählten Internet-Zielen "über die Leitung" gehen können.

Z.B. an einem Windows-PC kennt das PING-Kommando die Option -l size, in der "size" die Anzahl der Bytes angibt, die man als "Nutzlast" in ein ICMP-Echo- bzw. ICMPv6-Echo-Paket stecken möchte. Da der ICMP- bzw. ICMv6-Header eines Echo-Pakets 8 Bytes, und ein IPv4- bzw. IPv6-Header 20 bzw. 40 Bytes lang sind, erzeugt man bei Angabe von -l size ...

• ... im Fall von IPv4 ein ICMP-Echo-Paket der Gesamtlänge 20+8+size = size+28
• ... im Fall von IPv6 ein ICMPv6-Echo-Paket der Gesamtlänge 40+8+size = size+48

Z.B. an meinem Internetzugang (DG) habe ich eine WAN-MTU von 1500, die ich im Falle von IPv4 mit size=1500-28=1472 und im Falle von IPv6 mit size=1500-48=1452 jeweils voll ausnutzen würde. Mit size=1473 für IPv4 bzw. size=1453 für IPv6 hätte ich aber den Bogen überspannt.

Zur Demo nehme ich mal das Internet-Ziel google.com, dass für beide Protokolle pingbar ist:

• IPv4: google.com = 142.251.141.110
• IPv6: google.com = 2a00:1450:4001:813::200e

Test für IPv4 mit WAN-MTU=1500:

C:\>ping -4 -n 4 -f -l 1472 google.com.

Ping wird ausgeführt für google.com [142.251.141.110] mit 1472 Bytes Daten:
Antwort von 142.251.141.110: Bytes=1472 Zeit=7ms TTL=118
Antwort von 142.251.141.110: Bytes=1472 Zeit=8ms TTL=118
Antwort von 142.251.141.110: Bytes=1472 Zeit=7ms TTL=118
Antwort von 142.251.141.110: Bytes=1472 Zeit=6ms TTL=118

Ping-Statistik für 142.251.141.110:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 6ms, Maximum = 8ms, Mittelwert = 7ms

C:\>ping -4 -n 4 -f -l 1473 google.com.

Ping wird ausgeführt für google.com [142.251.141.110] mit 1473 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 142.251.141.110:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

Hier wird schön gezeigt, wie ein IPv4-Paket (mit gesetztem DF-Flag, erreicht über die Option -f) der Länge 1500 (size=1472) gerade noch über die Leitung geht, ein Paket mit der Länge 1501 (size=1473) aber gedropt wird.

Der IPv4-Destination-Cache meines Windows-PC zeigt mir entsprechend eine dynamisch ermittelte Path-MTU (PMTU) von 1500 für das IPv4-Google-Ziel 142.251.141.110 an:

C:\>netsh int ip sh dest

Schnittstelle 10: Ethernet


PMTU Zieladresse                           Adresse des n. Hops
---- --------------------------------------------- -------------------------
:    :                                             :
1500 142.251.141.110                               192.168.178.1
:    :                                             :

Test für IPv6 mit WAN-MTU=1500:

Analog das Ganze für IPv6:

C:\>ping -6 -n 4 -l 1452 google.com

Ping wird ausgeführt für google.com [2a00:1450:4001:813::200e] mit 1452 Bytes Daten:
Antwort von 2a00:1450:4001:813::200e: Zeit=9ms
Antwort von 2a00:1450:4001:813::200e: Zeit=6ms
Antwort von 2a00:1450:4001:813::200e: Zeit=8ms
Antwort von 2a00:1450:4001:813::200e: Zeit=7ms

Ping-Statistik für 2a00:1450:4001:813::200e:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 6ms, Maximum = 9ms, Mittelwert = 7ms

C:\>ping -6 -n 4 -l 1453 google.com

Ping wird ausgeführt für google.com [2a00:1450:4001:813::200e] mit 1453 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 2a00:1450:4001:813::200e:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

Und hierzu passend der IPv6-Destination-Cache meines Windows-PC:

C:\>netsh int ipv6 sh dest

Schnittstelle 10: Ethernet


PMTU Zieladresse                           Adresse des n. Hops
---- --------------------------------------------- -------------------------
:    :                                             :
1500 2a00:1450:4001:813::200e                      fe80::e208:55ff:fe3e:b83c
:    :                                             :

IPv6 kennt kein DF-Flag, daher kann man hier keine Option -f verwenden. Aufgrund der PMTU=1500 für die Zieladresse 2a00:1450:4001:813::200e weiß der PC aber, dass er ein IPv6-Paket der Größe 1501 fragmentieren muss. In einem parallel von mir erstellten Paket-Mitschnitt sieht man auch, dass tatsächlich zwei kleinere IPv6-Fragmente von jedem ICMPv6-Echo-Paket erzeugt werden. Die Google-Gegenstelle mag aber offensichtlich die IPv6-Fragmente eines ICMPv6-Echo-Pakets nicht wieder zusammenzusetzen und antwortet stattdessen gar nicht (was ich als "Zeitüberschreitung der Anforderung sehe").

Test-Vorschläge für den DS-Lite over PPPoE-Anschluss:

Interessant wäre nun mal, diese Tests an einem LAN-Rechner hinter dem DS-Lite-Router für folgende "sizes" auszuprobieren:

IPv6:

• size=1444 (Gesamt-Paketlänge = 1444+48=1492): ping -6 -n 4 -l 1444 google.com
• size=1445 (Gesamt-Paketlänge = 1444+48=1493): ping -6 -n 4 -l 1445 google.com

IPv4:

• size=1424 (Gesamt-Paketlänge = 1424+28=1452): ping -4 -n 4 -f -l 1424 google.com
• size=1425 (Gesamt-Paketlänge = 1425+28=1453): ping -4 -n 4 -f -l 1425 google.com
• size=1472 (Gesamt-Paketlänge = 1472+28=1500): ping -4 -n 4 -f -l 1472 google.com

Zitat von kostolany25

Auch die Seite U. a. auch die Seite dieses Forums oder z. B. test-ipv6.com.

Die Seite ist nur via IPv4 zu erreichen - das bedeutet, dass dein IPv4 (zumindest partiell) nicht funktioniert.

Zitat von kostolany25

NAT habe ich nun komplett ausgeschaltet, ohne dass dies nachvollziehbar Auswirkungen hat.

So soll es sein - es entlastet nur deinen Router.

Zitat von kostolany25

Nein, die einstellbaren Parameter sind in folgendem Bild zu sehen:

Kannst du mit einer SSH-Session auf die Kommandozeile deines Routers gehen? Die bietet möglicherweise mehr Konfigurationsmöglichkeiten als das Web-GUI. Aber ein mögliches MTU-Problem kann man ggf. auch später analysieren. Vielleicht ist dein Router auch so schlau, an dem genannten Schnittstellen die passenden MTU automatisch zu konfigurieren. Die könnte man dann ggf. durch Anzeige der konkretem Interface-Konfigurationen an der Kommandozeile sichtbar machen.

Mich würde interessieren, woran es bei IPv4 noch hakt. Kannst du an einem LAN-PC mal einen Dauerping ping -t test-ipv6.com starten, und am Router wieder den Traffic am WAN-Interface eth4 mitschneiden? 30 Sekunden müssten reichen.

Zitat von Tuffi

Ist mit "M-Flag=1" folgendes gemeint:

"1... .... = Managed address configuration: Set"?

Exakt!

Zitat von Tuffi

Dort sehe ich dann auch sehr schön wie es eigentlich richtig laufen sollte.

Wie Netze funktionieren, lernt man am besten durch Analyse von Paketmitschnitten ...

Ja, habe ich auch gelesen. Werden Jumbos nicht unterstützt, hat man für IPv6 eine MTU von 1500, bzw. von 1492, wenn PPPoE mit im Spiel ist. Heißt aber für jedes zu tunnelnde IPv4-Paket >1452, daß der Router als Tunnel-Endpunkt auf IPv6-Ebene fragmentieren, und der AFTR als der andere Tunnel-Endpunkt die Fragmente wieder reassemblieren muss. Das wäre vermeidbar, wenn die IPv4-Sender im LAN lernen würden, keine IPv4-Pakete größer als 1452 zu senden.

M.E. ist die MTU nur für Layer-3 Protokolle (IPv4, IPv6) relevant und sagt diesen, wie groß sie ihre Pakete inkl. Header werden lassen können, damit sie ohne Fragmentierung in die direkt darunter liegende L2-Ebene (oder um Falle von Tunneln eine Pseudo-L2-Ebene) verpackt werden können. Und nur diese L3-Protokolle haben (via ICMP und ICMPv6) entsprechende Control Plane-Funktionen (Path-MTU-Discovery), um diese MTUs der next hop-Interfaces eines Datenpfades zielspezifisch zu ermitteln.

Im DS-Lite-over PPPoE-Router ist das für des Senden/Weiterleiten von IPv6-Paketen der Wert 1492 an der Schnittstelle "PPP|PPPoe|Ethernet" und für das Senden/Weiterleiten von IPv4 der Wert 1452 am Tunnel-Interface "IPv6|PPP|PPPoe|Ethernet".

Ich wüsste jedoch nicht, dass man diese Werte (und dies auch noch protokoll-spezifisch) an den genannten Schnittstellen in so einem Router eingeben könnte. MTUs kann man nach meiner Kenntnis immer nur für ein physisches Interface definieren, und das wäre dann hier das Ethernet-Interface eth4 der WAN-Schnittstelle. Dort wäre folglich der Minimum-Wert von 1452 zu konfigurieren.

Aber ich lasse mich hier auch gerne eines besseren belehren:

Falls der Router es ermöglicht, MTU=1492 für die (logische) PPP-Schnittstelle und MTU=1452 für die (logische) Tunnel-Schnittstelle zu konfigurieren, wäre das die beste Lösung.

Zitat von ::1

Ich vermute, in deinem Router ist für IPv4 noch NAT aktiv, so dass er die Absende-Adressen aus deinem LAN durch die Tunneladresse 192.0.0.2 ersetzt. Dies widerspricht dem DS-Lite-Funktionsprinzip.

Bitte überprüfe das, und falls aktiv, schalte NAT im Router ab.

Was ist mit diesem Punkt?

Zitat von ::1

Alternativ kann ein LAN-Client die IPv4-Adresse bzw. IPv6-Adresse des LAN-Interface deines Routers als DNS-Server verwenden (die Werte werden in der Regel dynamisch zugewiesen). In diesem Fall greift die DNS-Proxy-Funktion des Routers: Er sendet einkommende DNS-Requests von LAN-Clients im Standardfall von seiner WAN6-Adresse via IPv6 an DNS1/DNS2 oder ggf. an andere von dir im Router statisch konfigurierte IPv6-DNS-Server weiter (z.B. die IPv6-DNS-Resolver von Cloudflare: 2606:4700:4700::1111 und 2606:4700:4700::1001).

Dein Router wird zur Namensauflösung standardmäßig die dynamisch zugewiesenen ISP-Server DNS1/DNS2 verwenden. Falls dein Router es ermöglicht, würde ich evtl. stattdessen im Router statisch die beiden Cloudflare-DNS-Server 2606:4700:4700::1111 und 2606:4700:4700::1001 eintragen. Der Mitschnitt zeigte ja Probleme mit den DNS-Antworten von DNS1 - die ließen sich somit umgehen. Dazu müsstest du m.E. in der WAN-Konfiguration die Option "Automatischer DNS-Server" deaktivieren und anschließend die IPv6-Adressen der Cloudflare-DNS-Server eintippen.

Zitat von kostolany25

So wie es aussieht, läuft es jedoch noch immer nicht ohne Probleme.

Und welche Probleme sind das jetzt genau?

Nachtrag:

Ich denke gerade noch über die MTU nach: Wegen des PPPoE+PPP-Vorspanns (8 Byte) müsste man die MTU für das WAN-Interface auf 1500-8=1492 absenken.

Für das IPv4-in-IPv6-Tunnel-Interface müsste man noch weitere 40 Bytes für den IPv6-Header abziehen. Das ergäbe eine nur für den getunnelten IPv4-Traffic maßgebliche MTU von 1492-40=1452.

Da die MTU für ein Interface protokollunabhängig ist, müsste man folglich das Minimum {1452, 1492} = 1452 einstellen.

Kannst du in deinem Router für das WAN-Interface (eth4) eine MTU von 1452 konfigurieren?

Zitat von Tuffi

Mein wireguard mitschnitt sieht wie folgt aus.

Du meinst vermutlich "Wireshark" ...

Ja der Mitschnitt bestätigt die Fehlermeldung "Keine Antwort vom DHCPv6-Server (SOL)": Der Router fragt per DHCPv6-Solicitation in Paket #85 nach IPv6-Parametern, der DHCPv6-Server der DG hat allerdings keine Lust zu antworten.

Immerhin erhältst du ab Paket #350 regelmäßig IPv6-RA. Sofern in diesen eine Router lifetime >0 und das M-Flag=1 gesetzt sind, wäre die inhaltlich korrekt.

Gegen einen nicht antwortenden DG-DHCPv6-Server kann nur DG weiterhelfen - aber das ist bekanntlich ein Trauerspiel.

kostolany25 : Ich habe mir die Paketmitschnitte angeschaut, die du mir per persönlicher Konversation hast zukommen lassen.

Für die interessierten Mitleser zitiere ich hier deine mitgegebene Zusatzinformation:

"ich habe den Anschluss jetzt nochmals leicht anders konfiguriert. Der UCG hat nun eine Verbindung hergestellt, jedoch mit den bekannten Problemen."

Die Situation ist nun also eine andere als in #157 und meiner dazu gehörigen Kommentierung in #158, bei der laut meiner Analyse kein IPv4-in-IPv6-Tunnel zustande gekommen ist.

Ich habe von dir die beiden Dateien eth4_neu.pcap und ip6tnl1_neu.pcap erhalten. Diese zeigen nun aber nicht die Initialisierung des WAN-Interface (=eth4), sondern eine spätere Betriebssituation nach Abschluss der Initialisierung bzw. Herstellung der Internetverbindung.

• eth4_neu.pcap enthält sämtlichen outbound/inbound-Traffic am WAN-Interface, der bei DS-Lite per Definition ausschließlich aus IPv6-Traffic (gekapselt in PPPoE) besteht.
• ip6tnl1_neu.pcap beinhaltet hingegen sämtlichen IPv4-Traffic, der outbound/inbound durch den IPv4-in-IPv6-Tunnel zwischen deinem Router und dem AFTR des ISP transferiert wird.

ip6tnl1_neu.pcap ist im Grunde redundant, denn jedes Paket in ip6tnl1_neu.pcap ist zugleich auch in eth4_neu.pcap enthalten, dort nur eben zusätzlich mit einem IPv6/PPPoE-Header versehen, hier mal anhand von Frame #17 beispielhaft verdeutlicht:

#17 in ip6tnl1_neu.pcap:

Frame 17: Packet, 45 bytes on wire (360 bits), 45 bytes captured (360 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 192.0.0.2, Dst: 1.1.1.1
Internet Control Message Protocol

#17 in eth4_neu.pcap:

Frame 17: Packet, 95 bytes on wire (760 bits), 95 bytes captured (760 bits)
Ethernet II, Src: Ubiquiti_8d:71:1b (28:70:4e:8d:71:1b), Dst: 42:8f:9d:22:b9:b4 (42:8f:9d:22:b9:b4)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 7
PPP-over-Ethernet Session
Point-to-Point Protocol
Internet Protocol Version 6, Src: 2a01:41e3:4xxx:xxxx:xxxx:xxxx:xxxx:xxx4, Dst: 2a01:41e3:ffff:cafe:face::4
Internet Protocol Version 4, Src: 192.0.0.2, Dst: 1.1.1.1
Internet Control Message Protocol

Wenn du in Wireshark für die geöffnete Datei eth4_neu.pcap den Ansichtsfilter ipv6.nxt==4 eingibst, erhältst du also dieselben Frames wie in ip6tnl1_neu.pcap, nur jeweils ergänzt um den IPv6/PPPoE-Header.

Im folgenden werde ich mich daher nur noch auf eth4_neu.pcap beziehen.

Grundsätzlich sind die Mitschnitt-Daten leider nicht vollständig, da zu lange Frames während des Captures einfach abgeschnitten werden: "[Packet size limited during capture]"

Hier meine Analyse:

Die gute Nachricht vorweg:

Es besteht nun ein funktionierender IPv4-in-IPv6-Tunnel gemäß der reinen DS-Lite-Lehre, wie in RFC6333 beschrieben.

Während der IPv6-Initialisierung des WAN-Ports per DHCPv6 (im Mitschnitt nicht enthalten, hier daher nur indirekt geschlossen) wurden deinem Router vom ISP (indirekt: PURtel.com) mindestens folgende Parameter zugewiesen:

• WAN-Portadresse (kurz "WAN6)": 2a01:41e3:4xxx:xxxx:xxxx:xxxx:xxxx:xxx4 (hier etwas verschleiert)
• DNS-Resolver-Adresse 1 (kurz "DNS1"): 2a01:41e1:ffff:f001::4
• DNS-Resolver-Adresse 2 (kurz "DNS2"): 2a01:41e0:10::6
• AFTR-Name: aftr.fra.purtel.com

Den AFTR-Name löst dein Router per DNS-Request (type AAAA) WAN6 -> DNS1 (Frame #2) + DNS-Reply DNS1 -> WAN6 (Frame #7) (Ansichtsfilter: udp.stream eq 0) wie folgt auf:

• aftr.fra.purtel.com = 2a01:41e3:ffff:cafe:face::4 (kurz "AFTR")

(im Mitschnitt ist der DNS-Reply leider abgeschnitten, aber aftr.fra.purtel.com ist über beliebige DNS-Resolver ebenfalls auflösbar)

Somit wird sämtlicher IPv4-Traffic innerhalb des IPv4-in-IPv6-Tunnels mit den beiden Endpunkten WAN6 <-> AFTR transportiert.

Prinzipiell können also sowohl nativ IPv6 als auch IPv4 (getunnelt zum AFTR) über die WAN-Verbindung zum ISP hin und her transportiert werden.

Und hier nun beobachtete Auffälligkeiten:

IPv6-LAN-Konfiguration:

Mit dem Ansichtsfilter ipv6.nxt!=4 kann ich mir ausschließlich den nativen IPv6-Traffic anschauen (der Tunnel-Traffic ist ausgeblendet). Es mag der Kürze des Mitschnitts von nur 27 Sekunden geschuldet sein: Aber mit Ausnahme der Frames #734, #735 (und einiger MLD-Reports und Router-Solicitations) sehe ich dort ausschließlich IPv6-Traffic von und zu WAN6, wobei es sich durchgängig um DNS-Requests und -Replies zu bzw. von DNS1 und DNS2 handelt und dabei fast ausschließlich Auflösungen von IPv4-Adressen (type A) vorkommen. Bei den Ausnahme-Frames #734, #735 handelt es sich um eine Kommunikation einer LAN-Adresse (2a01:41e3:yyyy:yyyy:yyyy:yyyy:yyyy:yyf7) ungleich WAN6 zu der externen IPv6-Adresse 2a06:98c1:3200::1 (ein STUN-Paket und ein Paket einer TCP-Session).

Da auch insgesamt fast ausschließlich DNS-Request mit type=A (Auflösung von IPv4-Adressen), jedoch extrem wenige DNS-Requests mit type=AAAA (Auflösung von IPv6-Adressen) auftreten, habe ich den Verdacht, dass möglicherweise deine LAN-Clients über keine bzw. ggf. nur unvollständige IPv6-Konfiguration verfügen:

Überprüfe bitte an deinen Clients, ...

1. ... ob sie jeweils (mindestens) über eine globale IPv6-Adresse verfügen, die mit "2a01:41e" beginnt, und ...
2. ... ob sie jeweils über ein IPv6-Standardgateway verfügen, das der linklokalen (fe80...) IPv6-Adresse des LAN-Interface deines Routers entspricht.

Teste auch, ob ein IPv6-Ping zu einem Internet-Ziel an jedem LAN-Client funktioniert.

DNS-Namensauflösung mit DNS1 scheitert teilweise:

Des weiteren fällt auf (Ansichtsfilter ipv6.nxt!=4 && icmpv6.type==1 ), dass dein Router fast alle DNS-Replies DNS1 -> WAN6 zu zuvor von ihm selbst gesendeten DNS-Requests WAN6 -> DNS1 verwirft und mit einer ICMPv6-Fehlermeldung "Destination unreachable / Port unreachable" an DNS1 quittiert. Wenn der Name nicht zugleich auch bei DNS2 erfragt wird, kann es hier also zu Auflösungsproblemen und in der Folge zu Zugriffsproblemen kommen. Warum dein Router den DNS1 nicht mag und dessen Antworten häufig verwirft, kann ich dir nicht beantworten.

IPv4-NAT im Router offenbar aktiv:

Wenn ich mir nun mit dem Ansichtsfilter ipv6.nxt==4 ausschließlich den IPv4-Tunnel-Traffic anschaue, fällt auf, dass sämtlicher Traffic ausschließlich von/zu der tunnelinternen IPv4-Adresse 192.0.0.2 des Routers ausgeht/addressiert ist. Diese Adresse sollte der Router allerdings nur verwenden, wenn er selbst IPv4-Traffic ins Internet sendet. IPv4-Traffic von LAN-Clients (in deinem Fall also von Absende-Adressen 192.168.0.0/24 bzw. 192.168.1.0/24) sollten "as is" durch den Router einfach über den Tunnel Richtung Internet weitergeleitet werden. Im Paketmitschnitt sehe ich allerdings keinerlei IPv4-Pakete aus deinen LAN-Ranges!

Ich vermute, in deinem Router ist für IPv4 noch NAT aktiv, so dass er die Absende-Adressen aus deinem LAN durch die Tunneladresse 192.0.0.2 ersetzt. Dies widerspricht dem DS-Lite-Funktionsprinzip.

Bitte überprüfe das, und falls aktiv, schalte NAT im Router ab.

Verwendung von IPv4-Resolvern:

Du solltest vermeiden, in einigen deiner LAN-Geräte statisch DNS-Server mit IPv4-Adressen zu konfigurieren (hier: 1.1.1.1), siehe Ansichtsfilter ipv6.nxt==4 && dns. Das belastet den AFTR des ISP mit unnötigen NAT-Session-States. Wenn schon, dann verwende bitte die IPv6-Adressen solcher DNS-Server.

Alternativ kann ein LAN-Client die IPv4-Adresse bzw. IPv6-Adresse des LAN-Interface deines Routers als DNS-Server verwenden (die Werte werden in der Regel dynamisch zugewiesen). In diesem Fall greift die DNS-Proxy-Funktion des Routers: Er sendet einkommende DNS-Requests von LAN-Clients im Standardfall von seiner WAN6-Adresse via IPv6 an DNS1/DNS2 oder ggf. an andere von dir im Router statisch konfigurierte IPv6-DNS-Server weiter (z.B. die IPv6-DNS-Resolver von Cloudflare: 2606:4700:4700::1111 und 2606:4700:4700::1001).

Zitat von kostolany25

Das sind die beiden Protokolle, welche über die Funktion "Packet Capure" aufgezeichnet wurden:

Das hilft schon etwas, aber leider noch nicht hinreichend. Kann dein Gerät auch einen vollständigen Paketmitschnitt (inklusive des vollständigen Inhalts aller Pakete) durchführen?

Was mir auffällt:

Im Verlauf für eth4 (= WAN-Interface!?):

8	0.162323	Ubiquiti_8d:71:1b	ba:c2:53:34:00:61	PPP IPCP	48	Configuration Request
10	0.164866	ba:c2:53:34:00:61	Ubiquiti_8d:71:1b	PPP LCP	    60	Protocol Reject

Wenn der Router für "DS-Lite over PPPoE" konfiguriert ist, sollte '8' hier nicht auftauchen - entsprechend weist die Gegenstelle in '10' das auch ab. Hintergrund: Der Router versucht hier (per IPCP) IPv4 via PPP zu konfigurieren. Bei DS-Lite wird aber nur IPv6 via PPP (via IPV6CP gemäß '9', '11', '12', '13') ausgehandelt. IPv4 wird anschließend via IPv6 getunnelt.

17	0.724223	fe80::2821:e850:e4da:304a	ff02::1:2	DHCPv6	185	Solicit XID: 0x7c5a68 CID: 000300012a704e8d7117 [Packet size limited during capture]
19	0.973240	fe80::bac2:53ff:fe34:61	fe80::2821:e850:e4da:304a	DHCPv6	228	Advertise XID: 0x7c5a68 CID: 000300012a704e8d7117 [Packet size limited during capture]
22	2.212667	fe80::2821:e850:e4da:304a	ff02::1:2	DHCPv6	213	Request XID: 0xfaa94b CID: 000300012a704e8d7117 [Packet size limited during capture]
23	2.366481	fe80::bac2:53ff:fe34:61	fe80::2821:e850:e4da:304a	DHCPv6	228	Reply XID: 0xfaa94b CID: 000300012a704e8d7117 [Packet size limited during capture]

Hier würde ich gerne in die Pakete hinein schauen können. um zu sehen, welche Parameter (IA_NA, IA_PD, Optionen) ausgehandelt werden. Insbesondere wäre hier auch interessant zu sehen, ob die "AFTR-Name option" enthalten ist.

14	0.302973	fe80::2821:e850:e4da:304a	ff02::16	ICMPv6	102	Multicast Listener Report Message v2
16	0.330198	fe80::2821:e850:e4da:304a	ff02::16	ICMPv6	102	Multicast Listener Report Message v2
18	0.800218	fe80::2821:e850:e4da:304a	ff02::16	ICMPv6	102	Multicast Listener Report Message v2
20	1.190204	fe80::2821:e850:e4da:304a	ff02::16	ICMPv6	102	Multicast Listener Report Message v2

Das ist normales Verhalten (MLD-Reports senden eines frisch initialisierten IPv6-Interface). fe80::2821:e850:e4da:304a ist die per IPV6CP ausgehandelte link-lokale IPv6-Adresse für das WAN-Interface deines Routers.

15	0.313006	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
21	1.366148	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
24	2.427327	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
25	4.519650	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
26	8.002486	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
31	13.480511	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
36	21.493585	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation

Hier bemüht sich dein Router, von der Gegenstelle endlich mal ein Router Advertisement (RA) zu bekommen. Was hier im Rahmen der Aufzeichnung allerdings nicht passiert. Bei fehlendem RA lernt der Router kein IPv6-Standardgateway. Da du aber von erfolgreichem IPv6-Traffic Richtung Internet sprichst, braucht dein Router offensichtlich auch keines, weil er IPv6-outbound-Traffic einfach über die PPP-Enkapsulierung raus sendet (dazu muss keine Hardware-Adresse der Gegenstelle via Hardware-Adressauflösung der Standardgateway-Adresse ermittelt werden).

Zu ip6tnl1:

1	0.000000	192.0.0.2	3.174.46.127	TCP	76	32998 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=2861564977 TSecr=0 WS=1024
2	0.347459	192.0.0.2	3.174.46.104	TCP	76	47460 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1049316850 TSecr=0 WS=1024
...

Dein Router geht hier davon aus, dass ein DS-Lite-Tunnel besteht. Das sieht man an der IPv4-Tunneladresse 192.0.0.2, die der Router verwendet, wenn er selbst mit dem Internet via IPv4 kommunizieren möchte. Deine Protokollierung zeigt aber, dass er immer nur outbound via IPv4 sendet, jedoch nie Antworten aus dem Internet erhält. De facto scheint also kein IPv4-Tunnel zu bestehen.

Außerdem sind die zahlreichen DNS-Requests via IPv4-Transport für einen DS-Lite-Router ein No Go:

18	12.411273	192.0.0.2	1.1.1.1	DNS	73	Standard query 0xd22b A ping.ui.com
19	12.411437	192.0.0.2	1.1.1.1	DNS	73	Standard query 0x3d86 A ping.ui.com
20	12.413018	192.0.0.2	1.1.1.1	DNS	73	Standard query 0xe576 A ping.ui.com
21	12.413138	192.0.0.2	1.1.1.1	DNS	73	Standard query 0x23a0 A ping.ui.com
22	12.413591	192.0.0.2	1.1.1.1	DNS	79	Standard query 0x9778 A www.microsoft.com
23	12.413693	192.0.0.2	1.1.1.1	DNS	79	Standard query 0x452e A www.microsoft.com
24	12.414263	192.0.0.2	1.1.1.1	DNS	72	Standard query 0x5434 A google.com
25	12.414368	192.0.0.2	1.1.1.1	DNS	72	Standard query 0x7c3d A google.com

Der Router sollte DNS-Requests stets per IPv6 an einen IPv6-fähigen DNS-Resolver schicken (um keinen unnötigen NAT-Session-State im AFTR zu generieren), die der ISP idealerweise im Rahmen der DHCPv6-Aushandlung zuweist. Woher kommt "1.1.1.1" bei deinem Router - falls von dir statisch konfiguriert, im Falle von DS-Lite eine schlechte Wahl. Wenn schon statisch, dann wähle bitte einen IPv6-DNS-Resolver (Cloudflare: 2606:4700:4700::1111 und 2606:4700:4700::1001).

Ohne einen vollständigen Paketmitschnitt kommen wir der Problemursache leider nicht wirklich näher.

Nachtrag:

Wenn ein IPv4-in-IPv6-Tunnel bestehen würde, müsste man für jedes IPv4-Paket in 'ip6tnl1' auch ein IPv6-Paket in 'eth4' sehen (mit proto=41, d.h. enkapsuliertes IPv4-Paket) - das ist offensichtlich nicht der Fall.