Deutsche Glasfaser IPv6 Routingprobleme

    Zitat von pufferueberlauf

    wenn die Firewall der FritzBox die Präfix-basierten Adressen der FritzBox nicht filtert sind die genau so gut wie die /64 Adresse der Fritzbox selber...

    Genau das tut sie aber. Man kommt von außen an ihre LAN Adresse nicht heran. Zunächst von außen ein Ping auf meine WAN Adresse, dann auf die LAN Adresse meiner Fritzbox:

    root@serv1:~# ping -6 fritz5530.<>
    PING fritz5530.<>(2a00:6020:1000:<> (2a00:6020:1000:<>)) 56 data bytes
    64 bytes from 2a00:6020:1000:<> (2a00:6020:1000:<>): icmp_seq=1 ttl=59 time=20.0 ms
    64 bytes from 2a00:6020:1000:<> (2a00:6020:1000:<>): icmp_seq=2 ttl=59 time=20.4 ms
    ^C
    --- fritz5530. ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1001ms
    rtt min/avg/max/mdev = 20.043/20.212/20.382/0.169 ms
    root@serv1:~# ping6 2a00:6020:a3<>
    PING 2a00:6020:a3<>(2a00:6020:a3<>) 56 data bytes
    From 2a00:6020:1000:<> icmp_seq=1 Destination unreachable: Administratively prohibited
    From 2a00:6020:1000:<> icmp_seq=2 Destination unreachable: Administratively prohibited
    From 2a00:6020:1000:<> icmp_seq=3 Destination unreachable: Administratively prohibited
    ^C
    --- 2a00:6020:a3<> ping statistics ---
    3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2004ms

    Und ich vermute, die "Antwort", die der TE oben in seinen Traces gesehen hat, war nicht die Ping Antwort, sondern die ICMP Nachricht "Administratively prohibited", die dann natürlich dazu führte, dass auf der Senderseite keine Antwort angezeigt wurde.

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

    Wie ich ihn verstanden habe, war die Bridge nur temporär drin.

    Ich sehe nicht, wie das eine Rolle spielen soll, denn Bridges sind unter Linux Dekaden alt.

    Aber an dieser Stelle würde ich auch Try/Error machen, siehe vorherigen Post.

    Ich hatte die Bridge nur reingemacht, um mit tcpdump Mitschnitte machen zu können, die beweisen, dass die Fritzbox am WAN Interface korrekt antwortet. Das Problem ist mit oder ohne Bridge absolut gleich.

    Die Symptome sind gleich. Ob das Problem gleich ist, weißt du nicht. Meines Erachtens steht nun folgendes an:

    • Paketmitschnitte über die Fritzbox anstatt über diese Bridge
    • Konkrete Überprüfung der verwendeten Adressen: Wann kommt die WAN Adresse der Box zum Einsatz, wann die LAN Adresse?
    • gezielte Verbindungsversuche zur WAN und zur LAN Adresse der Box mit einem detaillierten Vergleich der Ergebnisse in den Traces (Fritzbox und Gegenseite).
    Zitat von pufferueberlauf

    Dann waere es einen Versuch wert mal zu sehen ob der OP fuer diese LAN seitige GUA der Fritzbox eine Firewallregel bauen kann...

    Ich habe es auf der FB meines Bruders probiert.

    Man kann die Regel erstellen, sie bleibt aber wirkungslos. Ich vermute, da ist ein Reject (oder Drop?) mit höherer Priorität, bevor diese Regel greifen würde.

    In den Unübersicht (;)) fehlt mir die Info, mit welcher Adresse du die Box adressierst, DrFroeschle . Über die IP direkt oder über myfritz? Welche Adresse ist dort registriert?

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

    mbo77 ich lese die Adresse der Fritzbox aus über

    Internet - Onlinemonitor - Verbindungsdetails

    Internet, IPv6 listet die IPv6 Adresse mit der man normalerweise die Fritzbox ansprechen kann = myfritz Adresse (und mit der sie antworten würde, wenn diese nicht verschluckt würde)
    sowie den IPv6 Präfix für die Adressen hinter der Fritzbox.

    Code
    verbunden seit 21.12.2024, 11:55 Uhr, Deutsche Glasfaser
IPv6-Adresse: 2a00:6020:7380::xxxx/64, Gültigkeit: 2920/2920s
IPv6-Präfix: 2a00:6020:73df:xxxx::/56, Gültigkeit: 2920/2920s

    [habe FritzOS 8]

    Es muss nichts bedeuten, aber auffällig ist, dass in allen hier aktuell diskutierten Fällen mit IPv6-Problemen von gordrin , webwe und DrFroeschle die PD-Blöcke in 2a00:6020:7300::/40 bzw. sogar genauer in 2a00:6020:73d0::/44 liegen und die zugehörigen WAN-Port-Adressen in 2a00:6020:7380::/112. Ist evtl. ein neuer Block, den DG aktuell für Neuanschlüsse verwendet. Neu ist hier auch die Zuordnung der WAN-Port-Adresse zum PD-Block: An älteren Anschlüssen, z.B. denen mit PD-Blöcken aus 2a00:6020:4000::/36 liegen die zugeordneten WAN-Port-Adressen in 2a00:6020:1000::/48. In Traceroutes zu Zielen an diesen älteren Anschlüssen sieht man als letzte Etappe vor dem Kunden-Router Adressen aus 2a00:6020:ffff:ffff::/64 (lt. RIPE-DB als "BNG-Cluster-DHCPv6-Link-Address" benannt), diese habe ich in Traceroutes zu Zielen an den oben genannten Adressblöcken der neueren Anschlüsse noch nie gesehen.

    DG hat hier offenbar ein anderes Nummerierungs-Schema eingeführt, und man könnte vermuten, dass damit evtl. auch eine geänderte Access-Infrastruktur einher geht.

    Liegen die Anschlüsse im selben Ausbaugebiet oder zumindest in benachbarten PLZ-Bereichen?

    2 Mal editiert, zuletzt von ::1 (22. Dezember 2024 um 01:31)

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

    Also die mit 7380 im dritten Block?

    Hast du mal versucht, den Zugriff über HTTPS zuzulassen?

    Diese Adresse kannst du nicht pingen und es kommt auch kein Tunnel zustande, korrekt?

    korrekt,

    weder HTTPS, noch ping oder VPN (wireguard) funktionieren an dieser IPv6 Adresse.

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

    All diese Fragen könnten einfach beantwortet werden:

    Zitat von frank_m

    Meines Erachtens steht nun folgendes an:

    • Paketmitschnitte über die Fritzbox anstatt über diese Bridge
    • Konkrete Überprüfung der verwendeten Adressen: Wann kommt die WAN Adresse der Box zum Einsatz, wann die LAN Adresse?
    • gezielte Verbindungsversuche zur WAN und zur LAN Adresse der Box mit einem detaillierten Vergleich der Ergebnisse in den Traces (Fritzbox und Gegenseite).

    Bevor wir das nicht haben, bleibt alles Spekulation, und das können nur diejenigen ausführen, die betroffen sind.

    Die Funktion habe ich bisher nie in Anspruch genommen, aber ich finde aktuell keinen Anhaltspunkt, warum das auf der Fritzbox meines Bruders nicht funktionieren sollte.

    Wenn ich die Option "Internetzugriff auf die FRITZ!Box über HTTPS aktiviert" setze, kann ich trotzdem keine Verbindung zu weder der öffentlichen IPv4- noch der IPv6-Adresse herstellen. VPN habe ich jetzt aus Bequemlichkeit nicht getestet.

    Der Verbindungsaufbau zum angegeben Port schlägt mit einem "Permission denied" fehl. Der Name wird bei myfritz.net mit den richtigen Records gefüllt.

    Keine Idee, ob das mit meinen Versuchen, eine Portfreigabe für die LAN-seitige Adresse der FB zu setzen, zusammenhängt. Ich habe gerade aber auch keine Muße, die FB aus der Ferne zurückzusetzen und meinen Bruder anzuleiten, die Verbindung wieder herzustellen.

    Meine eigene FB (anderes Modell, aber auch FritzOS 8.00), die selbst nur Client hinter dem OpenWRT-Router ist, kann ich von einem dritten Anschluss aus erreichen, nachdem ich das WebUI freigegben habe und die FB einen Port gewürfelt hat. Den musste ich zwar in der FW des OpenWRT-Routers freischalten, aber das hat ja mit dem Problem nichts zu tun.

    Was ich auf Verdacht hin machen würde: Die FB bei den betroffenen Nutzern zurücksetzen und vergleichen.

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

    hier ein paar Mitschnitte aus der Fritzbox beim Versuch auf die freigegebene Seite per HTTPS zuzugreifen:
    (vertraulicher Port ersetzt durch ‚https‘)

    Im Browser kommt keine Antwort an, obwohl die Fritzbox antwortet.

    Code: tcpdump-fritzbox
    18:31:25.731800 IP6 2003:c1:1702:####::#.57378 > 2a00:6020:7380::####.https: Flags [S], seq 4162201288, win 65535, options [mss 1432,nop,wscale 6,nop,nop,TS val 2979843445 ecr 0,sackOK,eol], length 0
18:31:28.329007 IP6 2003:c1:1702:####::#.57379 > 2a00:6020:7380::####.https: Flags [S], seq 3014590594, win 65535, options [mss 1432,nop,wscale 6,nop,nop,TS val 3748686482 ecr 0,sackOK,eol], length 0
18:31:28.329650 IP6 2a00:6020:7380::####.https > 2003:c1:1702:####::#.57379: Flags [S.], seq 3683381592, ack 3014590595, win 28560, options [mss 1440,sackOK,TS val 155299884 ecr 3748686482,nop,wscale 7], length 0
18:31:29.330297 IP6 2003:c1:1702:####::#.57379 > 2a00:6020:7380::####.https: Flags [S], seq 3014590594, win 65535, options [mss 1432,nop,wscale 6,nop,nop,TS val 3748687483 ecr 0,sackOK,eol], length 0
18:31:29.330767 IP6 2a00:6020:7380::####.https > 2003:c1:1702:####::#.57379: Flags [S.], seq 3683381592, ack 3014590595, win 28560, options [mss 1440,sackOK,TS val 155300134 ecr 3748686482,nop,wscale 7], length 0
18:31:30.333566 IP6 2003:c1:1702:####::#.57379 > 2a00:6020:7380::####.https: Flags [S], seq 3014590594, win 65535, options [mss 1432,nop,wscale 6,nop,nop,TS val 3748688486 ecr 0,sackOK,eol], length 0
18:31:30.334005 IP6 2a00:6020:7380::####.https > 2003:c1:1702:####::#.57379: Flags [S.], seq 3683381592, ack 3014590595, win 28560, options [mss 1440,sackOK,TS val 155300385 ecr 3748686482,nop,wscale 7], length 0
  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    … und damit wir nicht immer nur auf die Fritzbox schauen,
    hier ein Versuch mit einer UCG-Ultra am Modem.

    Auch hier wird die Antwort dem Client NICHT zugestellt ;(

    der Wireguard client (via Mobilnetz) meldet:

    Code
    2024-12-24 15:42:14.618966: [APP] Status update notification timeout for tunnel 'UCG-Ultra-ClientTest2'. Tunnel status is now 'connected'.
2024-12-24 15:42:22.237744: [NET] peer(oeWC…8SFA) - Sending handshake initiation
2024-12-24 15:42:27.262843: [NET] peer(oeWC…8SFA) - Sending handshake initiation
2024-12-24 15:42:32.503766: [NET] peer(oeWC…8SFA) - Handshake did not complete after 5 seconds, retrying (try 2)
2024-12-24 15:42:32.504030: [NET] peer(oeWC…8SFA) - Sending handshake initiation
2024-12-24 15:42:37.563637: [NET] peer(oeWC…8SFA) - Handshake did not complete after 5 seconds, retrying (try 2)
2024-12-24 15:42:37.563979: [NET] peer(oeWC…8SFA) - Sending handshake initiation
2024-12-24 15:42:42.815101: [NET] peer(oeWC…8SFA) - Sending handshake initiation
2024-12-24 15:42:47.873025: [NET] peer(oeWC…8SFA) - Handshake did not complete after 5 seconds, retrying (try 2)
2024-12-24 15:42:47.873349: [NET] peer(oeWC…8SFA) - Sending handshake initiation

    Und der passende Mitschnitt sieht so aus:

    Das ist ein Anfang, aussagekräftig werden die Teaces aber erst mit den entsprechenden Ergänzungen. Siehe meine Beiträge weiter oben. Im Moment sehen wir nicht mehr, als wir schon wussten.