nftables IPv6 Regeln: ICMPv6 nicht möglich

  • Guten Abend,


    ich beschäftige mich aktuell mit der Einrichtung von nftables auf einem vServer und stoße dabei auf Probleme mit den ICMP Regeln für IPv6. Mein Setup ist folgendes:


    - Debian Stretch

    - nftables 0.9.0 aus den Backports


    Um IPv4 und IPv6 mit einem Ruleset bedienen zu können nutze ich die inet Familie von nftables. IPv4 bereitet dabei keine Probleme, sowohl Pings als auch SSH funktionieren. Nach aktivieren der Regeln ist mein Server jedoch für ICMPv6 nicht mehr erreichbar. Mit leerem Ruleset arbeiten beide Protokolle wie gewünscht.


    Meine Input Chain sieht so aus:


    Zunächst dachte ich, dass ICMPv6 zu stark beschnitten ist, aber selbst wenn (wie oben) alle diesbezüglichen Pakete akzeptiert werden kann mein Server über IPv6 keine Pings beantworten. Versucht habe ich bereits:

    - ICMPv4 erweitert (ip protocol icmp icmp type { destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem } accept)

    - ct state new accept statt nur accept bezogen auf ICMPv6


    Grundsätzlich verstehe ich nicht, wo hier der Fehler liegt. Mit iptables und ip6tables gab es keine Probleme. Die nftables Regeln funktionieren mit IPv4. Die IPv6 Adresse ist richtig eingerichtet und pingbar mit leerem nftables Ruleset. Die Regeln für den Umgang mit ICMPv6 sollten eigentlich alles akzeptieren. Trotzdem ist nach aktivieren von nftables keine Verbindung über IPv6 möglich. Leider habe ich selbst keinen IPv6 fähigen Internetanschluss, sodass ich auf die Online Pings diverser Webseiten angewiesen bin.


    Sieht jemand von euch den Fehler?



    Danke für die Hilfe im Voraus.


    Gruß


    MaxMusterman

  • Hallo,


    IPv6 ist bekanntlich auf ICMPv6 angewiesen, da es ARP in IPv6 ersetzt. Um nun das vorliegende Problem zu lösen, möchte ich um folgende Schritte ersuchen:

    1. Konfiguriere IPv6 statisch, verzichte auf DHCPv6 - Gateway ist fe80::1

    2. Archlinux hat eine gute Anleitung mit Use-Cases (Workstation, Server, ...) https://wiki.archlinux.org/index.php/nftables
    Deine Regeln scheinen restriktiver zu sein.


    Dass Dein Internetanschluss kein natives IPv6 kann, soll Dich nicht hindern, IPv6 für den Heimanschluss zu erhalten.

    Es gibt auch nach dem Ende von Sixxs nach wie vor Tunnelbroker wie etwa https://tunnelbroker.net/ (Hurricane Electric), und es steht auch weiterhin 6to4 zur Verfügung, auch wenn deren Anycast-Routing asymmetrische Routen bewirken kann. Weitere sind hier verzeichnet: https://de.wikipedia.org/wiki/Liste_von_IPv6-Tunnelbrokern

  • Guten Abend,

    vielen Dank für die Antwort. Zu deinen Vorschlägen:


    1. IPv6 (und auch IPv4) sind bereits statisch konfiguriert. ifconfig und das Verhalten ohne aktive nftables Regeln entsprechen dem erwarteten Verhalten.

    2. Das Arch Wiki habe ich auch bereits zu Rate gezogen, bisher erfolglos.


    Ich danke dennoch für Vorschlag 2 und werde das ganze mit einem einfacheren Ruleset testen. Ein Beitrag bei (afair) Stackexchange, den ich leider nicht mehr finde, hat einen Bug in Bezug auf nftables, IPv6 und conntrack angesprochen. Allerdings dachte ich, dass die nftables Version aus den Backports diesen bereits gefixt hat. Eventuell habe ich diesbezüglich auch einen Fehler in meinem Ruleset. Ich melde mich, sobald ich dies testen konnte.

  • 1. IPv6 (und auch IPv4) sind bereits statisch konfiguriert. ifconfig und das Verhalten ohne aktive nftables Regeln entsprechen dem erwarteten Verhalten.

    Anstelle von ifconfig würde ich ip -6 a s verwenden.

    Neighbors zeigt ip -6 n oder ip -6 n s


    Ich würde bei echo req allenfalls das rate limit setzen, mehr auch nicht. echo replies sollen jedenfalls rausdürfen, da würde keine Regeln erstellen.

    Ansonsten haben wir das Thema hier im Forum immer wieder und meine Antwort lautet immer wieder - lasst icmpv6 soweit wie möglich in Ruhe. Für die anderen Types - ndisc sollte jedenfalls auch ungehindert passieren. Wenn es sich um einen Server und keinen Router handelt, kann man über das /proc-FS Kerneloptionen setzen, die dazwischenpfuschen könnten.

  • Ich konnte heute die vereinfachte Version testen. Kopiert man blind die Regeln aus dem Archwiki für eine simple IPv4/IPv6 Firewall ist der Server anschließend für keinerlei Pings mehr erreichbar. Klar, bei IPv6 fehlt in diesen Regeln unter anderem Type 128 und 129. Ich kann nicht ganz nachvollziehen, wieso dieser Eintrag so im Wiki bestand hat.


    Meine aktuellen Regeln sehen nun wie folgt aus:



    Mit diesen Regeln klappen Pings wie gewohnt - dennoch frage ich mich, ob die Konfiguration optimal ist. Ich wüsste trotzdem gerne, welche ICMP Typen (IPv4 und IPv6) tatsächlich gebraucht werden, um Ping-Funktionalität und natürlich Erreichbarkeit ermöglichen zu können. Ich danke dir, eripeks, für den Hinweis ICMPv6 weitestgehend in Ruhe zu lassen.

  • IPv6 Konnektivität bedeutet nicht, dass ein Ping funktionieren muss.

    D.h. deine ursprünglichen Regeln waren soweit ich es überflogen haben ausreichend, so dass dein Host via IPv6 erreichbar ist, aber ICMPv6 Echo-Requests/Replys hast du in der Firewall schlicht blockiert (was man auch so machen kann).


    Grundsätzlich halte ich die Filterung von ICMP(v6) für nicht nötig, höchstens ein Rate Limit, damit nicht zu viele Ressourcen für diese Pakete verwendet werden. Den auch ohne ICMP(v6) Echo-Requests/Replys (Ping) kann man feststellen, ob ein IP(v6)-Adresse im Netz erreichbar ist.


    IGMP zuzulassen (wie in deinem letzten Post) halte ich für unnötig. Die wenigsten spielen im freien Internet mit Multicast rum und daher wird es dort auch nicht benötigt ;)

  • D.h. deine ursprünglichen Regeln waren soweit ich es überflogen haben ausreichend, so dass dein Host via IPv6 erreichbar ist, aber ICMPv6 Echo-Requests/Replys hast du in der Firewall schlicht blockiert (was man auch so machen kann).

    Für v4 und v6: Message-too-big (!) beachten.