Deutsche Glasfaser IPv6 Routingprobleme

    Ich meine schon: Es würde deine Vermutung entkräften, weil es dann keinen zu haltenden "State für diese IP" gibt. Bitte Worte wie "Haarspalterei" vermeiden, kommt nicht gut.

    Wie und warum sollte ein Router ein Paket droppen? Das kann nur die Firewall machen. Oder worauf willst du hinaus?

    Zumindest augenscheinlich verwirft die Firewall ausschließlich Pakete des WAN-Interfaces, zu der sie keine gültige, selbst-initiierte Verbindung kennt. So wie man es auch aus anderen Firewall-Systemen kennt, wie z.B. iptables.

    Und wenn du nur so eine Phrase hinhaust, ohne deinen Gedankengang zu erklären, klingt es schon verdächtig nach "Herr Lehrer, ich weiß was!".

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

    Ich hab mal ganz dumm die künstliche Intelligenz befragt, wie das routertechnisch z.B. bei einem Cisco Router aussehen könnte. Hatte ehrlich gesagt zum letzten Mal vor 19 Jahren einen Cisco Router auf der Konsole, aber sei's drum. Vielleicht stimmt das ja so ungefähr, was die AI so raushaut:

    Q: Can a Cisco router block ICMP between two connected hosts in a way, that PING is possible from host "A" to host "B", but when initated from host "B", then the "Echo reply" packets from host "A" are blocked?

    A: Yes, a Cisco router can be configured to block ICMP traffic asymmetrically, such that ping (ICMP Echo Request and Reply) works from Host A to Host B but not in the reverse direction. This behavior can be achieved through the use of Access Control Lists (ACLs) or other traffic filtering mechanisms on the router. Here's how this could happen:

    Scenario Analysis

    • Ping from Host A to Host B succeeds:
      • Host A sends an ICMP Echo Request to Host B.
      • The router allows the ICMP Echo Request from Host A to Host B.
      • Host B responds with an ICMP Echo Reply to Host A.
      • The router allows the ICMP Echo Reply from Host B to Host A.
    • Ping from Host B to Host A fails:
      • Host B sends an ICMP Echo Request to Host A.
      • The router allows the ICMP Echo Request from Host B to Host A.
      • Host A responds with an ICMP Echo Reply to Host B.
      • The router blocks the ICMP Echo Reply from Host A to Host B, resulting in no response.

    How This Can Be Configured on a Cisco Router

    1. ACL Blocking Specific Traffic:
      • The router might have an Access Control List (ACL) configured to filter ICMP traffic in a specific direction.

      • Example ACL configuration:

        Code
        access-list 101 permit icmp any any echo
access-list 101 deny icmp any any echo-reply
access-list 101 permit ip any any

        Applied to the relevant interface (e.g., interface GigabitEthernet0/1):

        Code
        interface GigabitEthernet0/1
ip access-group 101 in

        This configuration permits ICMP Echo Requests but denies ICMP Echo Replies in the direction applied.

    2. Stateful Inspection or Reflexive ACLs:
      • If stateful inspection (via CBAC, ZBF, or similar) is improperly configured, it could allow ICMP Echo Requests but fail to recognize or permit Echo Replies.
      • Reflexive ACLs might be set up but not applied correctly for return traffic.
    3. Routing or NAT Issues:
      • A Network Address Translation (NAT) or routing issue might block return ICMP traffic in one direction, although this is less common than ACL filtering.
    4. Policy-Based Routing (PBR):
      • Policy-based routing could selectively redirect or block specific ICMP traffic based on the source, destination, or type of packet.

    Dann gab es noch Infos wie man das diagnostiziert und behebt und eine Conclusion. Lasse ich jetzt mal weg.

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

    Wie und warum sollte ein Router ein Paket droppen? Das kann nur die Firewall machen. Oder worauf willst du hinaus?

    Exakt!

    Ich gehe aber nicht davon aus, dass ein ISP, der ja im Wesentlichen nur Traffic zwischen dem Internet und seinen Kunden routen soll, Firewalls im Datenstrom platziert. Jedenfalls nichts, was "State" und "Sessions" halten muss (außer bei CGNAT, da sind NAT-Sessions halt ein notwendiges Übel). Wenn überhaupt, dann sind vielleicht Paketfilter im Spiel, die stateless arbeiten, und in einem Router vielleicht Pakete droppen, die z.B. als Ergebnis eines Reverse-Path-Forwarding-Checks "zum falschen Interface" herein kommen.

    Aber gut, ich habe keine Einblicke in das Innenleben eines ISPs - falls du oder sonst jemand da Erfahrungswerte liefern kann, gerne mehr.

    Zitat von DrFroeschle

    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.

    Hier besteht ein gewisses Restrisiko, dass die Annahme falsch ist. Das hast du bislang nur von deinem merkwürdigen Bridgekonstrukt überprüft, von dem wir nicht wissen, wie es den Verkehr beeinflusst.

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

    DrFroeschle danke für die Analyse.

    Ich habe nun seit ein paar Tagen auch Glasfaser bei der DG, und bin schon am verzweifeln.

    Die Beschreibung für Site2Site Verbindung mit zwei Fritzboxen wirkt so einfach, aber sie will einfach nicht funktionieren.

    VPN mit wireguard geht auch nicht.

    Und wie von Dir beschrieben funktionieren (meistens) die delegierten IPv6 Adressen.

    Auf mein Ticket gab es noch keine Reaktion.

    Die Asymmetrie kann ich bestätigen.
    Im Logfile der Fritzbox wurde die VPN Verbindung bestätigt, der Client wartet aber weiterhin auf seine Antwort die nicht ankommt.

    Zitat von DrFroeschle

    Was allerdings hilft, ist ein nslookup auf fritz.box von einem der Clients im Heimnetz. Da bekomme ich dann von dem FB dnsmasq die Adresse ausgehändigt. Mit dieser habe ich dann vom VPS Server im Internet aus einen traceroute6 gemacht:

    Und diese Adresse ist dann:

    Zitat von DrFroeschle

    root@vmdabcdef:/etc# traceroute6 2a00:6020:73d7:xxxx:3ea6:2fff:fe44:zzzz

    Es ist also eine Adresse aus dem PD-Block 2a00:6020:73d7:5900::/56, die zur Fritzbox gehört.

    Andererseits lautet die IPv6-Adresse deines Test-Webservers im LAN 2a00:6020:73d7:5900:223:55ff:fe:fc:5155, liegt also auch im PD-Block 2a00:6020:73d7:5900::/56, nur eben nicht auf der Fritzbox.

    Jetzt haben wir die Beobachtung:

    Werden die beiden Adressen von außen angesprochen, dann ...

    1. ... kommt von 2a00:6020:73d7:5900:3ea6:2fff:fe44:zzzz (Adresse auf Fritzbox) keine Antwort zurück-
    2. ... kommt von 2a00:6020:73d7:5900:223:55ff:fe:fc:5155 (Adresse auf Webserver im LAN) eine Antwort zurück.

    Wenn nun die These ist, dass im DG-Netz irgendein Router im ersten Fall das Antwort-Paket droppt, frage ich mich anhand welchem Kriteriums er das tun sollte. Die These war ja: Immer wenn die Adresse zu Fritzbox gehört, wird gedroppt, sonst nicht. Woran soll aber die droppende Instanz im DG-Netz erkennen, dass 2a00:6020:73d7:5900:3ea6:2fff:fe44:zzzz zur Fritzbox, 2a00:6020:73d7:5900:223:55ff:fe:fc:5155 aber zu einem Webserver im LAN gehört? Es sind einfach zwei Adressen aus dem PD-Block 2a00:6020:73d7:5900::/56.

    Insofern halte ich die These des "droppenden DG-Routers" für nicht plausibel und sehe die Ursache des Problems eher doch lokal auf Kundenseite.

    Das war auch mein Gedanke.

    Ich hätte verstanden, dass das WAN-Prefixes ohne dazu gehörige Verbindung droppt, aber nicht beim delegierten Prefix.

    Andererseits bleibt es bei der Beobachtung, dass das Paket die Fritzbox wieder verlässt.

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

    Andererseits bleibt es bei der Beobachtung, dass das Paket die Fritzbox wieder verlässt.

    Zitat von ::1

    Insofern halte ich die These des "droppenden DG-Routers" für nicht plausibel und sehe die Ursache des Problems eher doch lokal auf Kundenseite.

    Ja, auf der Suche nach möglichen lokalen Ursachen hat sich meine These der zwei unterschiedlichen MAC-Adressen am WAN-Port (einfach spekulativ aus der Angabe, dass es ein aus LAN1 umkonfigurierter WAN-Port ist) als nicht haltbar ergeben.

    Bleibt noch:

    Zitat von frank_m

    Hier besteht ein gewisses Restrisiko, dass die Annahme falsch ist. Das hast du bislang nur von deinem merkwürdigen Bridgekonstrukt überprüft, von dem wir nicht wissen, wie es den Verkehr beeinflusst.

    Vielleicht sollte man dieses Bridgekonstrukt tatsächlich mal entfernen, um es als Fehlerursache auszuschließen.

    Zitat von ::1

    Vielleicht sollte man dieses Bridgekonstrukt tatsächlich mal entfernen, um es als Fehlerursache auszuschließen.

    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.

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

    Woran soll aber die droppende Instanz im DG-Netz erkennen, dass 2a00:6020:73d7:5900:3ea6:2fff:fe44:zzzz zur Fritzbox, 2a00:6020:73d7:5900:223:55ff:fe:fc:5155 aber zu einem Webserver im LAN gehört? Es sind einfach zwei Adressen aus dem PD-Block 2a00:6020:73d7:5900::/56.

    Genau das ist der Punkt. Ich hatte weiter oben ja auch schon mal den Verdacht geäußert, dass vielleicht die interne Adresse der Fritzbox aus dem delegierten Prefix genutzt wird, aber nicht die WAN Adresse der Box. Das würde dann natürlich zuverlässig erklären, warum die Antworten nicht beim Sender ankommen.