Aus der Erinnerung: Schau mal unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IPv6-Einstellungen -> IPv6-Adressen -> Verwendete IPv6 Präfixe
Welche der IPv6-Adressen liegt denn davon im LAN?
Tscha, und was soll ich sagen, hängt am gleichen Hop wie wenn ich die dedizierte FB IPv6 Adresse verwende
Das ist der letzte Hop vor der Fritzbox. Kann auch einfach daran liegen, dass die Box keine ICMPs aussendet.
Alle diese Pakete gehen mit der 2a00:6020:7380::1735 als Source IP ab.
Also, wenn ich für diese WAN-Port-Adresse deiner Fritzbox dieselben Traceroute-Tests durchführe, die ich hier bezogen auf das Problem von gordrin durchgeführt habe, dann erhalte ich auch dieselben (negativen) Ergebnisse, wie dort beschrieben:
Mit fällt auf, dass deine WAN-Port-Adresse "ungewöhnlich ist": In allen Fällen, die ich bisher gesehen habe, liegen die WAN-Port-Adressen von DG-Anschlüssen im Range 2a00:6020:1000::/48
Ergänzung:
Tscha, und was soll ich sagen, hängt am gleichen Hop wie wenn ich die dedizierte FB IPv6 Adresse verwende. Und wie ich in meinem eigenen Forumsthread schon geschrieben hatte: Wenn ich einen Webserver im "Heimnetz" einrichte und diesen per IPv6 an der Fritzbox freischalte, dann kann ich auf diesen zugreifen. Nur die Rückrouten direkt für die Fritzbox-Services werden am DG Router geblockt (meine Vermutung).
Aus deinen Angaben reime ich mir trotz "Obfuskierung" zusammen:
Dein PD-Block ist 2a00:6020:73d7:5900::/56. Und egal, ob es in diesem Block einen nach außen freigeschalteten Webservice gibt oder nicht, sollte ein Traceroute von außen für jede beliebige Adresse von 2a00:6020:73d7:5900:0:0:0:0 bis 2a00:6020:73d7:59ff:ffff:ffff:ffff:ffff als letzte Etappe vor deinem Router eine Adresse aus 2a00:6020:ffff:ffff::/48 aufweisen, so zumindest das Ergebnis meiner Traceroute-Analysen zu vielen anderen DG-Kundenanschlüssen. Das sehe ich für den PD-Block deines Anschlusses allerdings nie: Egal, welche beliebige Adresse aus dem Block ich wähle, das Traceroute-Ergebnis ist stets so, wie für deine WAN-Port-Adresse 2a00:6020:7380::1735 oben beschrieben.
Aber gut, vielleicht ist es unzulässig, meine Beobachtungen zu verallgemeinern, und für neuere Anschlüsse mögen sie nicht mehr zutreffen.
Nur noch eine Idee:
Ist in deiner Fritzbox der "Stealth Mode" (Diagnose | Sicherheit | Filter) aktiv? Falls ja, könnte es helfen, den mal zu deaktivieren. Dann könnte man evtl. auch die WAN-Port-Adresse deiner Fritzbox in Traceroutes sehen.
[...]
Nur noch eine Idee:
Ist in deiner Fritzbox der "Stealth Mode" (Diagnose | Sicherheit | Filter) aktiv? Falls ja, könnte es helfen, den mal zu deaktivieren. Dann könnte man evtl. auch die WAN-Port-Adresse deiner Fritzbox in Traceroutes sehen.
Hab gerade nachgesehen. Nein, der Stealth Mode ist nicht aktiv.
Mit dem testweise freigeschalteten HTTP Server (Alles aus dem Präfix tut ja, nur die Fritzbox selbst nicht) komme ich auf folgenden Graphen von ipv6tech.ch:
Deine Box taucht dort aber auch nicht auf. Sie scheint also keine ICMPs zu senden.
Übrigens fungiert die WAN Adresse deiner Box ja als Router für dein Prefix. Von daher kann die WAN Adresse auf jeden Fall aus dem Netz der DG erreicht werden, sonst würde auch dein delegiertes Prefix nicht funktionieren.
Die Frage ist ja, ob seitens SG eingehende Verbindungen zu der Adresse geblockt werden, wenn es dazu keine bestehende Verbindung gibt.
Das scheint mir jedenfalls hier der Fall zu sein.
Am Telekom-Anschluss auf einem OpenWRT-Router kann ich jedenfalls die IP-Adressen des WAN- und des LAN-Interfaces erreichen, wenn ich das in der Firewall zulasse.
Ich denke, das sollte bei DG eigentlich identisch gehandhabt werden.
Ich weiß aber auch nicht, welche IP-Adresse die FB im DynDNS registriert.
DG akzeptiert am DG-Anschluss ja nur eine einzige MAC-Adresse.
Blöde Idee:
Falls deine Fritzbox in Antwortpaketen zu Requests aus dem Internet (zu Diensadressen auf der Fritzbox selbst) eine andere MAC-Adresse als für Weiterleitungspakete von Clients/Servern in deinem LAN verwendet, würden diese vom "DG-Router" gedropt. Das würde zumindest das beobachtete Verhalten erklären.
Man könnte das durch Paketmitschnitte am WAN-Port der Fritzbox herausfinden (vergleiche den Trace mit den gedropten SYN/ACKs mit dem ausgehenden Traffic von Clients).
Nachtrag:
Und falls dem so ist, könnte es evtl. daran liegen, dass LAN1 hier als Ersatz für einen echten WAN-Port herhalten muss - das mag dann zu solchen Effekten führen.
Wieso sollte eine andere MAC eine Rolle spielen?
Ein- wie ausgehend geht das über das selbe Interface. Aber vielleicht verstehe ich deine Idee momentan nicht.
Und falls dem so ist, könnte es evtl. daran liegen, dass LAN1 hier als Ersatz für einen echten WAN-Port herhalten muss - das mag dann zu solchen Effekten führen.
Das wäre aber schon mal aufgefallen, oder? Wie viele nutzen eine Fritzbox hinter dem ONT in diesem Modus? Gäbe es da ein generelles Problem, ich glaube, wir wären hier im Forum drüber gestolpert.
Ansonsten klingt das prinzipiell plausibel.
Zur Vermutung "unterschiedliche MACs": Siehe nachfolgende Screenshots von Wireshark. Es handelt sich um ein Ping Request und Reply Paar zur Fritzbox, mitgeschnitten am WAN Interface (ein wesentlicher Vorteil gegenüber einer Glasfasermodem-Fritzbox).
Request:
Reply:
Wie zu sehen ist, sind die MACs symmetrisch.
Dieses Reply Paket wird dann vom DG BNG Router gedroppt.
Ich habe heute erfahren, dass in unserem Dorf noch die Anwerbestelle der Deutschen Glasfaser geöffnet hat. Ich werde da morgen mal hingehen und ein Interview führen zum Thema Servicequalität bei meinem Ticket, welche seit dem 30.11. dort unbearbeitet rumliegt...
Und wenn du von einem IPv6-fähigen LAN-Client einen IPv6-Ping auf ein beliebiges Internet-Ziel absetzt (und dabei einen Trace am WAN-Port laufen lässt), wird dieses ICMPv6-echo auch mit der Source-MAC-Adresse 3c:a6:2f:44:18:37 weitergeleitet (damit wollte ich es vergleichen)?
Und wenn du von einem IPv6-fähigen LAN-Client einen IPv6-Ping auf ein beliebiges Internet-Ziel absetzt (und dabei einen Trace am WAN-Port laufen lässt), wird dieses ICMPv6-echo auch mit der Source-MAC-Adresse 3c:a6:2f:44:18:37 weitergeleitet (damit wollte ich es vergleichen)?
Bitteschön:
Request:
Reply:
Gleiche MACs
Ich habe heute erfahren, dass in unserem Dorf noch die Anwerbestelle der Deutschen Glasfaser geöffnet hat. Ich werde da morgen mal hingehen und ein Interview führen zum Thema Servicequalität bei meinem Ticket, welche seit dem 30.11. dort unbearbeitet rumliegt...
Das kannst du gerne Versuchen, aber die Erfolgschancen da irgendwas zu klären sind verschwindend gering.
Das sind Vertriebler (die wahrscheinlich nicht mal bei der DG arbeiten), erwartest du von denen eine Auskunft zu einem Support Ticket?
Erklärt es mir bitte noch einmal: Wo hätte denn die zweite MAC herkommen sollen?
Und an DrFroeschle: Der Ping war demnach erfolgreich oder kommt die Antwort nicht mehr bei der Quelle an?
Erklärt es mir bitte noch einmal: Wo hätte denn die zweite MAC herkommen sollen?
Und an DrFroeschle: Der Ping war demnach erfolgreich oder kommt die Antwort nicht mehr bei der Quelle an?
Ping von Heimnetz Node zu VPS Server: funktioniert vollständig.
Ping von VPS Server zu Heimnetz Node: funktioniert vollständig.
Ping von VPS Server zu FritzBox: Request kommt an, Fritzbox sendet nachweislich den Reply raus, Reply kommt nie beim VPS Server an. Wird höchstwahrscheinlich vom DG BNG Router gedroppt.
Gleiches Schema gilt für UDP und TCP Traffic.
OK, dann wird der DG-Router den State für diese IP nicht halten und das Paket verwerfen, da es zu keiner initiierten Session passt.
Da es in letzter Zeit an mehreren Stellen in der IPv6-Konfiguration bei DG geknirscht hat, bin ich nicht gänzlich überrascht.
Entweder lässt du den WG-Tunnel von einem anderen Endpoint halten oder musst drauf hoffen, dass DG den Fehler irgendwann entdeckt, versteht und behebt.
OK, dann wird der DG-Router den State für diese IP nicht halten und das Paket verwerfen, da es zu keiner initiierten Session passt.
Ein Router ist keine Firewall ...
