Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    ... danke für die Aufklärung. Dann nochmal meine Frage: Wo ist da die Stelle in der DS-Lite-Konfiguration, bei der man Angaben zum AFTR machen muss? Oder wird danach nicht gefragt, weil der AFTR-FQDN implizit per DHCPv6-Option "DS-Lite Name" erfragt und anschießend aufgelöst wird?

    Ohne AFTR eben kein IPv4-over-IPv6-Tunnel und damit kein IPv4.

    TP-Link kenne ich nicht. Bei Unifi gibt es dies, leider nicht klar formuliert. Zumindest sollte sich hinter dieser Funktion "verbergen".
    Ich habe kein DS-Lite, kann es nicht testen. Aber in der https://community.ui.com wurde es als funktionierend bestätigt.

    Aber ich vermute, dass seine Kombi mit TP-Link und dahinter die UCG-Ultra irgendwie verkonfiguriert ist.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von Phino

    Ja, das sind Screenshot aus der Unifi-Oberfläche.
    Das Problem ist, dass kostolany25 immer wieder eine neue Baustelle aufmacht. Er setzt 2 Router ein in seinem Netz, ohne hinreichendes Verständnis für Netzwerke. :roll:

    Der UCG-Ultra erwartet ein Eingangssignal auf dem WAN-Port, ansonsten funktioniert er nicht. Diesen WAN-Zugang kann man (meinem Verständnis nach im Ergebnis vergleichbar mit der Einstellung in Deinem Thread #139) so konfigurieren (mittels Static IP), dass der vom TP-Link hergestellte Internetzugang auch an der UCG ansteht. Das ist ja auch auf dem Bild IMG_1752 zu sehen. Hier wurde selbstverständlich nicht die WAN-Konfiguration mittels DS-lite over PPPoE vorgenommen.

    Zitat von Phino

    Aber ich vermute, dass seine Kombi mit TP-Link und dahinter die UCG-Ultra irgendwie verkonfiguriert ist.

    Das was mich irritiert ist, dass wenn ich die UCG außen vor lasse und den TP-Link an meinen ersten Unifi-Switch anschließe, zu den beschriebenen Problemen kommt. Als ob die dann nicht „gemanagten“ Unifi-Geräte das Problem verursachen. Wenn der TP-Link standalone über sein WLAN genutzt wird, ist alles in Ordnung.

    kostolany25 : Das Problem ist, dass man von dir immer nur bruchstückhaft erfährt, was du so treibst, bzw. man nie so genau weiß, auf welchen Netzaufbau du dich gerade beziehst. Bei gezeigten Screenshots wird bspw. nicht genannt, von welchem Gerät sie stammen.

    Mit ist z.B. erst jetzt klar geworden (bzw. war das zuvor meinerseits nur eine Vermutung), dass

    • du offenbar neben deinem UCG-Ultra weiteres Unify-Equipement besitzt, z.B. den soeben erwähnten Switch,
    • der UCG-Ultra nicht direkt am Internetzugang hängt und diesen per DS-Lite over PPPoE herstellt, sondern dass dies dein vorgelagerter TP-Link tut - somit hast du eine Router-Kaskade.

    Ich weiß immer noch nicht, ob dein Ziel-Szenario diese Router-Kaskade sein soll, oder ob der TP-Link 'raus fliegen und durch den UCG-Ultra ersetzt werden soll. Nur letzteres passt übrigens zu diesem Thread "Unifi sucht Tester für DS-Lite i. V. m. PPPoE" - deine Kombi UCG-Ultra hinter TP-Link ist hier insofern deplatziert.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Also ich habe nach wie vor keinen einzigen funktionsfähigen DS-Lite an UniFi Router mit PPPoE gesehen. Entweder funktionierte der Tunnel oder IPv6, nicht Beides. Konnte jemand was Anderes feststellen?

    Zitat von ::1

    Ich weiß immer noch nicht, ob dein Ziel-Szenario diese Router-Kaskade sein soll, oder ob der TP-Link 'raus fliegen und durch den UCG-Ultra ersetzt werden soll. Nur letzteres passt übrigens zu diesem Thread "Unifi sucht Tester für DS-Lite i. V. m. PPPoE" - deine Kombi UCG-Ultra hinter TP-Link ist hier insofern deplatziert.

    Sorry, das hat sich leider so entwickelt.

    Wie meinem zweiten Thread (#100) zu entnehmen kst, bin ich mit der UCG direkt an dem ONT gestartet, da das schon immer mein Plan war. Dies resultierte leider in dem Fehler, welchen ist seitdem immer wieder habe: Internetseiten sind teilweise nur sporadisch erreichbar, augenscheinlich IPv4-Seiten. Deshalb habe ich versucht, als der TP-Link-Router keine Probleme mehr gemacht hat, diesen als Router zu verwenden mit der UCG als Management-Konsole dahinter für mein restliches Netzwerk. Auch hier treten die Problem jedoch wie zuvor auf.

    Mein Netzwerk besteht neben der UCG aus insgesamt 3 Switchen und 4 APs von Unifi. Im Netzwerk selbst hängen die übliche Anzahl an Handys, Tablets, Notebooks, etc. einer 4-köpfigen Familie sowie ca. 40 Shelly-Komponenten und eine NAS.

    Zitat von DLMttH

    Also ich habe nach wie vor keinen einzigen funktionsfähigen DS-Lite an UniFi Router mit PPPoE gesehen. Entweder funktionierte der Tunnel oder IPv6, nicht Beides. Konnte jemand was Anderes feststellen?

    Das würde mich auch interessieren. Ich habe nach meinen unzähligen Versuchen auch den Verdacht, dass diese Funktion bislang noch nicht sauber implementiert ist.

    Zitat von DLMttH

    Also ich habe nach wie vor keinen einzigen funktionsfähigen DS-Lite an UniFi Router mit PPPoE gesehen. Entweder funktionierte der Tunnel oder IPv6, nicht Beides.

    Wenn der Tunnel (und somit IPv4) funktioniert, muss auch eine IPv6-Verbindung bestehen, zumindest zwischen dem UniFi-Router und dem AFTR des ISP. Bzgl. IPv6 muss dann noch etwas anderes schief laufen, z.B. dass kein LAN-Präfix per DHCPv6-PD vorhanden ist. Der Router müsste bzw. sollte aber in der Lage sein, DNS-Namensauflösung per Kontaktierung der ISP-Resolver via IPv6 durchzuführen (z.B. um IPv4-Ziele aufzulösen). Der Router sollte hier als DNS-Proxy/Forwarder arbeiten, der DNS-Requests per IPv4 aus dem LAN entgegen nimmt und diese per IPv6 weiterleitet.

    Kannst du oder kostolany25 für das Szenario "DS-Lite an UniFi Router mit PPPoE" Logdaten des Routers oder gar einen Paket-Mitschnitt am WAN-Port des Routers für den Verbindungsaufbau zum ISP beisteuern?

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von ::1

    Kannst du oder kostolany25 für das Szenario "DS-Lite an UniFi Router mit PPPoE" Logdaten des Routers oder gar einen Paket-Mitschnitt am WAN-Port des Routers für den Verbindungsaufbau zum ISP beisteuern?

    D. h. vor dem Einstecken des Kabel auf „Packet Capture“ gehen? Reichen 30 Sekunden?

    Zitat von ::1

    Der Router müsste bzw. sollte aber in der Lage sein, DNS-Namensauflösung per Kontaktierung der ISP-Resolver via IPv6 durchzuführen (z.B. um IPv4-Ziele aufzulösen). Der Router sollte hier als DNS-Proxy/Forwarder arbeiten, der DNS-Requests per IPv4 aus dem LAN entgegen nimmt und diese per IPv6 weiterleitet.

    Was muss ich da wo einstellen?

    Noch folgendes zur Info, wenn auch wieder off Topic:

    Ich habe mir jetzt sowohl die UCG als auch die Switche resetet (also Werksreset) und alles komplett neu eingestellt. Ergebnis beim Betrieb der UCG hinter dem TP-Link: IPv4-Seiten sind sowohl im Unifi-Netz (192.168.1.x) als auch im TP-Link-Netz (192.168.0.x) nur sehr sporadisch zu erreichen. IPv6 funktioniert augenscheinlich problemlos.

    Zitat von kostolany25

    D. h. vor dem Einstecken des Kabel auf „Packet Capture“ gehen? Reichen 30 Sekunden?

    Wie du das an deinem Unify-Router genau durchführen kannst, kann ich dir leider nicht sagen, da ich mit dem Dingens keinerlei Erfahrungen habe. Aber dein Ansatz klingt gut. 30 Sekunden oder eben mindestens so lange, bis die Internet-Verbindung steht.

    Wenn du das Ergebnis als ETH- oder PCAP-Datei speichern kannst, könnte man es mit Wireshark anschauen/auswerten. Ergänzende Log-Daten aus dem Router wären auch vorteilhaft, sofern der sowas bietet. Vorsicht mir dem Hochladen von Paketmitschnitten hier im Forum, die könnten vertrauliche Daten (z.B. PPP-Authentifizierung) enthalten. Du könntest mir das zur Auswertung per privater Konversation schicken.

    Zitat von kostolany25

    Was muss ich da wo einstellen?

    Gar nichts, das ist das Funktionsprinzip von DS-Lite, das du in RFC6333 nachlesen kannst.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von kostolany25

    Sorry, das hat sich leider so entwickelt.

    Das würde mich auch interessieren. Ich habe nach meinen unzähligen Versuchen auch den Verdacht, dass diese Funktion bislang noch nicht sauber implementiert ist.

    Aber genau dafür gibt es doch die community.ui.com Release-Plattform, bei der man die Probleme einbringt und seine Support-Dateien hinterlegt. Man wird dann direkt vom Dev-Team angesprochen. Es bringt doch rein gar nichts bei einer Beta-Entwicklung hier es zu versuchen es zu lösen. Dort haben jedenfalls es bei einigen funktioniert und bei anderen nicht.
    Erst heute sind viele Verbesserungen und Fehlerbereinigungen in der EA-Version herausgekommen. Dies passiert bei EA im Wochentakt. Also, wenn man sich dort einbringt, werden Probleme sehr zeitnahe angegangen.
    Verbesserungen

    • Insgesamt wurden Multicast TX-Pakete in den AirView-Diagrammen hinzugefügt.
    • Zusätzliche Unterstützung für die Helligkeitsregelung U7 APs.
    • Access Point Filter wurde zum Airview Radio-Bereich hinzugefügt.
    • WiFi-Nutzungsdiagramm in der Seite Clients hinzugefügt.
    • Unterstützung für MTU/MSS-Einstellungen für VPN-Server und VPN-Clients hinzugefügt.
    • Sortierung für die Hotspot Gutscheintabelle hinzugefügt.
    • Starlink Firmware-Status und Hindernissedetails wurden im Dashboard hinzugefügt.
    • Es wurde 6GHz WiFi-Erlebnis im AP-Seitenteil hinzugefügt.
    • "Zugriffspunktname in Beacon anzeigen" zu den WiFi-Einstellungen hinzugefügt.
    • Die Schaltfläche "Notizen" in der Gerätetabelle wurde hinzugefügt.
    • Details zum Gerätemodell und zur Firmware-Version im linken Port-Manager-Bedienfeld hinzugefügt.
    • Die Option zum Erweitern von Long List Filters auf volle Höhe für eine bessere Benutzerfreundlichkeit wurde hinzugefügt.
    • Hinweise für verfügbare Updates im Dashboard hinzugefügt.
    • AirTime-Diagramme wurden in den Radio-Abschnittsfeldern hinzugefügt.
    • PDU Power Actions im Alarm Manager hinzugefügt.
    • Erlauben Sie das Deaktivieren von Wireless Meshing, wenn Meshing verwendet wird.
    • Erlauben Sie das Klicken auf die Verbindungsspalte, um das Bedienfeld Client/Gerät in Port Manager zu öffnen.
    • Die Port Manager-Benutzererfahrung für Offline-Geräte wurde verbessert.
    • Verbesserte Latenzzeit für die Anwendung von Konfigurationsänderungen.
    • Die Topology-Benutzererfahrung für größere Setups wurde verbessert.
    • Verbessert die AirTime-Auslastungsdiagramme Benutzererfahrung.
    • Die Dashboard-Benutzererfahrung für mehrere WAN-Setups wurde verbessert.
    • Verbesserte Validierung über die Einstellungen hinweg.
    • Verbessert die Benutzererfahrung der Geräteakzeptanz.
    • Verbesserte die Meshed AP Side Panel Benutzererfahrung.
    • Verbesserte Ausfallsicherheit für die Wiederherstellung von Sicherungen.
    • Die Benutzererfahrung für die AirTime-Auslastung im AP-Seitenteil wurde verbessert.
    • Die MC-LAG-Benutzererfahrung wurde verbessert.
    • Verbessert das Widget „Aktivster Client“ im AP-Seitenfenster.
    • Verbesserte Anwendungsstabilität.
    • Die Netzwerk-API wurde verbessert.
    • DNS - Erstellen und Verwalten von DNS-Richtlinien
    • Firewall - Firewall-Richtlinien erstellen und verwalten.
    • VPN - Listen Sie VPN-Server und Site-To-Site-Tunnel auf
    • Die Benutzererfahrung zur Konfiguration statischer IP-Adressen für Geräte wurde verbessert.
    • Verschobene Netzwerklisten und RADIUS-Server in die Netzwerkeinstellungen.
    • AirTime-Diagramme wurden in das AP Insights-Panel verschoben.
    • Verschobene Paketerfassung zum Access Point-Seitenteil.
    • Den WLAN-Client-Ping-Test wurde in die Client-Seitenwand verschoben.
    • Verschobener Wireless Client Airtime Graph in das Client-Seitenfeld.
    • Die Einstellung für das Feld Interface Refresh Rate wurde entfernt.
    • Es wird jetzt immer automatisch angepasst.
    • Die Backup-Option für Netzwerkanwendungen wurde entfernt.
    • Sie müssen nun die Backup-Option in der Control Plane verwenden.
    • DHCP Manager in IP-Tabelle umbenannt.

    Bugfixes

    Es wurde ein Problem behoben, durch das der 5GHz Roaming-Assistenz-Umschalter nicht korrekt funktionierte.
    Es wurde ein Problem behoben, durch das der WLAN-Blackout-Planer in seltenen Fällen falsch angegebene Zeitbereiche auswählen konnte.
    Es wurde ein Problem behoben, durch das die Schaltfläche Gutschein hinzufügen für die Hotspot-Operatoren nicht verfügbar war.
    Inkonsistente Datenberichterstattung zwischen dem Netzwerkanwendungs-Dashboard und dem Site Manager ISP Viewer wurde behoben.
    Es wurde ein Problem behoben, durch das die WLAN-MAC-Filterwerte nach dem Umschalten der MAC-Filterung gelöscht wurden.
    Es wurde ein Problem behoben, durch das Systemstatistiken nicht für 5G-Geräte gemeldet wurden.

    Zitat von ::1

    Wie du das an deinem Unify-Router genau durchführen kannst, kann ich dir leider nicht sagen, da ich mit dem Dingens keinerlei Erfahrungen habe. Aber dein Ansatz klingt gut. 30 Sekunden oder eben mindestens so lange, bis die Internet-Verbindung steht.

    Wenn du das Ergebnis als ETH- oder PCAP-Datei speichern kannst, könnte man es mit Wireshark anschauen/auswerten. Ergänzende Log-Daten aus dem Router wären auch vorteilhaft, sofern der sowas bietet. Vorsicht mir dem Hochladen von Paketmitschnitten hier im Forum, die könnten vertrauliche Daten (z.B. PPP-Authentifizierung) enthalten. Du könntest mir das zur Auswertung per privater Konversation schicken.

    Gar nichts, das ist das Funktionsprinzip von DS-Lite, das du in RFC6333 nachlesen kannst.

    Das ist eigentlich recht simpel. Man sucht sich halt den Anschluss raus und sagt, wie lange der Mitschnitt laufen soll.

    Mein Problem ist ja, ich habe kein DS-Lite, sondern Dual-Stack mit öffentlicher IPv4. Kann es also nicht testen.

       

    Gerade neues UnifiOS-Update reingekommen. Alles Weihnachtsgeschenke. ;)

    Einmal editiert, zuletzt von Phino (24. Dezember 2025 um 19:12)

    Gerade gesehen vor 2 Wochen wurde ein Problem mit PPPoE und DS-Lite behoben bei der offizellen Version behoben, man ist da dran. Aktuell ist die EA-Version bei 10.1.68

    UniFi Network Application 10.0.162 enthält den unten aufgeführten Bugfix.

    • Es wurde ein Problem behoben, durch das der WLAN-Blackout-Planer in seltenen Fällen falsch angegebene Zeitbereiche auswählen konnte.
    • Es wurde ein Problem behoben, durch das LAG-Verbindungen in seltenen Fällen nicht auf UXG-Enterprise/EFG hergestellt werden konnten.
    • Es wurde ein Problem behoben, bei dem die WAN-Überwachung in seltenen Fällen nicht für DS-Lite über PPPoE funktionierte.
  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

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

    eth4:


    ip6tnl1:

    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!?):

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

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

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

    Code
    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:

    Code
    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:

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

    2 Mal editiert, zuletzt von ::1 (26. Dezember 2025 um 16:10) aus folgendem Grund: Typos + Style

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

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

    Zur Verifizierung, nicht das ich der Analyse nicht trauen würde, es erhärtet das Ergebnis, habe ich mich auf eine Fritze im Netz von Deutsche GigaNetz via Wireshark verbunden und dort mal nachgesehen:

    IPv4 wird über DS-Lite genutzt
    AFTR-Gateway: aftr.fra.purtel.com
    IPv4-MTU: 1500
    Breitband-PoP: mx.fra4 oder mx.fra2 oder mx.fra1 oder mx.fra3 oder mx.fra5

    IPv4
    verbunden seit 27.12.2025, 03:51 Uhr, Deutsche GigaNetz
    FRITZ!Box verwendet einen DS-Lite-Tunnel
    AFTR-Gateway: 2a01:41e3:ffff:cafe:face::4

    IPv6
    verbunden seit 27.12.2025, 03:51 Uhr, Deutsche GigaNetz
    IPv6-Adresse: 2a01:41e3:0:1::fa:.., Gültigkeit: 84918/84918s
    IPv6-Präfix: 2a01:41e3:256e:4100::/56, Gültigkeit: 84918/84918s

    Genutzte DNS-Server 2a01:41e0:10::6 (aktuell genutzt für Standardanfragen)
    2a01:41e1:ffff:f001::4

    Bemerkenswert hierbei ist, das DGN bzw. Purtel 12 Stunden nach der durch die Fritze ausgelöste Anfrage einer neuen IP-Adresse (Vermeidung der Zwangstrennung) eine neue IPv6 Adresse und ein neues Präfix vergibt.