IPv6 in einem Nerd-LAN mit Firewall und VLANs

  • Moin!


    Nach 2-3 fehlgeschlagenen Versuchen meinem Router an einem Deutsche Telekom Anschluss IPv6 beizubringen habe ich das Thema vor ein paar Jahren in die Ecke geschmissen, es mit Benzin überschüttet und angezündet. Heute habe ich es noch mal Versucht und mit folgender Anleitung klappte es auf Anhieb. Schon fast zu einfach. Bin jetzt also auch im Club der IPv6 na(t)?ives.


    Jetzt stellt sich mir eine Frage:


    Ich habe hier Zuhause diverse VLANs und einen Server der auch Dienste fürs Internet bereit stellt.


    Wenn alles via DHCPv6 dynamisch konfiguriert wird, wie konfiguriere ich das in der Firewall? Regeln auf Interface Level würden ja alle Clients im VLAN betreffen, und einzelne IPv6 Adressen funktionieren ja nicht, da dynamisch.


    Ich habe einen DNS Primary welcher auch DynDNS kann und eine Firewall die mit DNS Names statt IPs arbeiten kann. Ist das die einzige Option?


    Finde das irgendwie gruselig... <X

  • Bei IPv6 sollte man / muss man letztendlich immer unterscheiden zwischen Clients und Server im Netz:

    • für Clients sollte man parallel SLAAC (-> Router Advertisments in pfSense/opnsense, type assisted) und DHCPv6 für das gleiche Subnetz einrichten. Grund: Es gibt Clients die können nur SLAAC und andere nur DHCPv6.
    • für Server sollte man eine static v6 direkt am Server eintragen; wenn man einen dynamisch wechselnden Prefix hat, ist dies natürlich ein Problem. Dann muss doch wieder prefix translation ran, sprich du kannst intern die ULA (Unique Local Adressen) vergeben, und nach außen hin auf den dynamischen Prefix mappen (sofern opnsense das schon kann, pfsense kann es noch nicht).

    Weiterhin: das kleinste bei IPv6 zur Verfügung stehende Netz ist ein /64, don't split it or stuff will break.

    Prinzipiell könnte man sich auch über einen VPS/Root-Server ein statisches /64 pro Interface über ein VPN nach hause routen. Da Netcup aber wie ich in diesem Thread schonmal breit erörtert habe, seine Hausaufgaben bzgl. IPv6 nicht richtig gemacht hat, ist dies nur zu äußerst absurden Aufpreisen für viele Interfaces möglich. Oder man routet sich lediglich ein einzelnes /64 Netz nach hause und wendet dort dann wieder NPt an. Aber auch dann müsste man das NAT nur verwenden, weil der Provider es nicht korrekt implementiert hat und mindestens ein /56 pro Kunde zuweist. Aus diesem Grund habe ich nach wievor IPv6 einfach komplett deaktiviert, da ich nicht einsehe für IPv6 im Jahr 2021 extra zu bezahlen.


    Ich denke vor allem Hostingprovider können sich das Spiel noch so lange erlauben, so lange es noch genügend IPv4 Adressen gibt. Sobald hier akute Knappheit herrscht, wird der Druck auf größere IPv6 Netze größer werden bzw. sämtliche Services in die Big Cloud verschoben, da die noch viel länger IPv4 Adressen haben werden.

  • wenn man einen dynamisch wechselnden Prefix hat, ist dies natürlich ein Problem. Dann muss doch wieder prefix translation ran, sprich du kannst intern die ULA (Unique Local Adressen) vergeben, und nach außen hin auf den dynamischen Prefix mappen (sofern opnsense das schon kann, pfsense kann es noch nicht).

    Warum ULA? Gibt es eine Einschränkung bei OpenSense, dass es nicht mit dynamischen Prefixes zurecht kommt? Die Firewall muss bei einem neuen Prefix ggf. umkonfiguriert werden, aber das sollte man automatisieren können (das kann ja heute schon jede Fritzbox). Für die Benutzung von ULAs sehe ich da im Moment keinen Grund.

    Da Netcup aber wie ich in diesem Thread schonmal breit erörtert habe, seine Hausaufgaben bzgl. IPv6 nicht richtig gemacht hat

    Wie beschrieben kann man darüber sehr geteilter Meinung sein. Wenn man die Definition der RFCs in Bezug auf "Site" und "Host" akribisch auslegt, dann macht Netcup exakt das, was in den Standards empfohlen wird. Auch wenn ich zugebe, dass zusätzliche /64 Netze auf einem VPS oder RS zuweilen hilfreich wären, aber auch dann hat man kostenlose Möglichkeiten, wie ich im verlinkten Thread ja auch ausgeführt habe.

  • für Clients sollte man parallel SLAAC (-> Router Advertisments in pfSense/opnsense, type assisted) und DHCPv6 für das gleiche Subnetz einrichten

    Schau ich mir mal an, aber so wie es aussieht können alle Clients auf die es ankommt DHCPv6, von daher wird es wahrscheinlich nicht notwendig sein.


    sprich du kannst intern die ULA (Unique Local Adressen) vergeben, und nach außen hin auf den dynamischen Prefix mappen

    Das klingt ziemlich abgedreht. Und irgendwie nach NAT.


    ULAs selbst werde ich mir mal anschauen, um lokal ein fixes Prefix zu haben. Aber das mappen auf dynamische Prefixes scheint noch nicht von OPNSense (sie bitten um helfende Hände beim implementieren des Features) unterstützt zu sein. Und es ist NAT, was unsexy ist.


    das kann ja heute schon jede Fritzbox

    Auf Interface-Level kann OPNSense das auch. Nur gibt es halt keine Möglichkeit die Firewall Regeln für eine einzelne IPv6 Adresse zu aktualisieren, wenn sich der Prefix ändert.



    Bin fast versucht das ganze über die OPNSense/DynDNS API abzufackeln und bei einem Prefix Change via Script die Firewall Regeln/Aliases und die DNS Einträge zu aktualisieren. Denn in meinem Fall geht es um einen einzelnen Reverse Proxy, der die Dienste nach außen exposed.


    Oder ich lass es einfach ganz, mache IPv6 nur für Clients und der Rest bleibt v4-only.

  • ips fuer server konfiguriere ich bei debian mit

    iface ethx inet dhcp

    pre-up /sbin/ip/ token set ::42 dev ethx

    gentoo:

    preup()

    ip token set ::42 dev ethx

    }

    der id teil kann man sich dann merken. und aenert sich nicht

    clients las ich die anomysierten ips, da alle die ip dem dns-server melden muss ich die auch nicht wissen.

    zur firewall eigentlich sollte heutzutage jede firewall ipv6 koennen wie auch ipv4.

    ich muss nur dienste fuer server freischalten.

  • eigentlich sollte heutzutage jede firewall ipv6 koennen

    Kann die Firewall ja auch. Nur das absolut dynamische Zuweisen von IPs verwirrt mich. Ich verstehe halt nicht wie ich damit Firewall Regeln für einen einzelnen Client machen soll, ohne den in ein separates VLAN zu stecken.


    Das mein DNS auch die AAAA Records vom DHCP mitgeteilt bekommt lässt sich bestimmt auch einstellen, nicht das Problem. Hilft aber bei den Firewall Regeln nicht wirklich.

  • Ich verstehe halt nicht wie ich damit Firewall Regeln für einen einzelnen Client machen soll, ohne den in ein separates VLAN zu stecken

    Ist die OpenSense Firewall nicht letztlich iptables basiert? Dann verstehe ich nicht, warum dafür ein VLAN nötig sein sollte.


    Es ist doch so, dass man ein Prefix vom Provider bekommt und das Gerät hat eine statische Host-ID. Aus Prefix und Host-ID ergibt sich die Zieladresse, die auch Bestandteil der Firewall Regel sein muss. Beispiel:

    Code
    ip6tables -A FORWARD -i eth0 -p tcp -d <prefix1>::1 --dport 8080 -j ACCEPT

    Jetzt bekommt man ein neues Prefix vom Internetprovider, folglich bekommt das Gerät eine neue IP: <prefix2>::1. Vermutlich werden sich durch das neue Prefix diverse Firewallregeln ändern. Da bei iptables die Reihenfolge der Regeln ja wichtig ist, würde ich jetzt erwarten, dass der Router einmal den kompletten Regelsatz löscht und alle Regeln neu anlegt und dabei das neue Prefix beachtet. Wenn der Router das nicht selber kann, kann man sich auch auf Basis eines Scriptes selber was bauen.

  • Ist die OpenSense Firewall nicht letztlich iptables basiert?

    Nope, FreeBSD. Ist ein Fork von pfSense. Kein iptables.


    Da bei iptables die Reihenfolge der Regeln ja wichtig ist, würde ich jetzt erwarten, dass der Router einmal den kompletten Regelsatz löscht und alle Regeln neu anlegt und dabei das neue Prefix beachtet.

    Genau das fehlt da noch. Offenes Issue auf GitHub, soweit ich sehe. Hatte gehofft dass es da was eleganteres gibt. Weil kann ja eigentlich nicht sein, dass sowas essentielles zurecht gehackt werden muss.


    kann man sich auch auf Basis eines Scriptes selber was bauen.

    Wenns gar nicht anders geht muss ich das wohl... Baue dann einfach nen Hook in meinen DynDNS Update Mechanismus rein, der auch das entsprechende IPSet in der Firewall aktualisiert...


    Die komplette IP Vergabe kann automatisch ablaufen. Aber für die Firewall muss sich wieder jeder Router Hersteller was eigenes ausdenken. Absurd.

  • Die komplette IP Vergabe kann automatisch ablaufen. Aber für die Firewall muss sich wieder jeder Router Hersteller was eigenes ausdenken. Absurd.

    Der Grund ist, dass IPv6 niemals dafür vorgesehen war, die Cashcow von dynamisch wechselnden Prefixen + Business-Tarif Aufpreis wenn du static willst weiter zu melken.

  • Die komplette IP Vergabe kann automatisch ablaufen. Aber für die Firewall muss sich wieder jeder Router Hersteller was eigenes ausdenken. Absurd.

    Es gibt halt unterschiedliche Implementierungen von Firewalls. Da ist es schwer bis unmöglich, etwas zu standardisieren. Letztlich ist es doch auch hier nur eine Frage, wer sich die Mühe macht, und mal was dafür aufsetzt. Wenn es dann einmal was gibt für iptables, nftables, ufw oder was auch immer, dann können wieder alle davon profitieren. Die grundsätzlich erforderlichen Mechanismen bringen ja alle mit.

    Das ist bei er Umsetzung der Adressierung ja auch nicht anders, nur dass dort eben viele auf die bereits vorhandenen Implementierungen setzen und deshalb der individuelle Implementierungsaufwand sinkt.


    Der Grund ist, dass IPv6 niemals dafür vorgesehen war, die Cashcow von dynamisch wechselnden Prefixen + Business-Tarif Aufpreis wenn du static willst weiter zu melken.

    Ich glaube kaum dass damals bei der Standardisierung bereits diese spezifischen kommerziellen Modelle der ISPs eine Rolle gespielt haben. Zumal die Standardisierung eher von Unternehmen wie HP, Alcatel und Cisco vorangetrieben wurde, weniger von Telekom, Verizon oder AT&T.

  • Wie beschrieben kann man darüber sehr geteilter Meinung sein. Wenn man die Definition der RFCs in Bezug auf "Site" und "Host" akribisch auslegt, dann macht Netcup exakt das, was in den Standards empfohlen wird. Auch wenn ich zugebe, dass zusätzliche /64 Netze auf einem VPS oder RS zuweilen hilfreich wären, aber auch dann hat man kostenlose Möglichkeiten, wie ich im verlinkten Thread ja auch ausgeführt habe.

    Hmm, naja vielleicht kann man sich darauf einigen, dass es einfach von Netcup nicht zu ende gedacht bzw. alles andere als kundennah ist. Wobei man dazusagen muss, dass es, was das Thema betrifft, noch weitaus schlimmere Hoster gibt. Aber es gibt auch jene, die es richtig machen, und die Anzahl derer wird zwangsweise steigen. Netcup liegt irgendwo dazwischen.


    Wenn ich beispielsweise 20 Container auf einem Root-Server laufen lassen will und diese per Firewall voneinander trennen will, brauch ich 20 Netze, da ich 20 virtuelle Bridges/Switches zu je /64 IPv6 habe. Klar könnte man subnetten, aber wie gesagt, das ist so in IPv6 nicht vorgesehen. Das gleiche gilt eigentlich für NAT/NPd. Ein externes Netz von zB. HE auf einen RS zu binden, halte ich nicht für wirklich sinnvoll - da wirst du niemals die Bandbreite von zB. 2.5Gbit/s bekommen.


    Und: Imho ist das bei Netcup inkludierte /64 Subnetz seines Namens nicht wert, weil es ein geswitchtes Netz ist und kein geroutetes. Die korrekte Umsetzung wäre beispielsweise ein /128 (eine Adresse) auf den Server, worauf dann das /64 geroutet wird. Oder halt wie es hier der Fall ist ein geswitchtes /64 + das richtige (ein geroutetes) oben drauf.


    Es hat schon seinen Grund, warum selbst Privatkunden bei DSL Anschlüssen ein geroutetes /56 Netz bekommen: Weil man per Philosophie von IPv6 als Kunde niemals an den Punkt stoßen sollte, wo man sich beschränkt fühlt. Und dass ein Kunde zuhause mehr als 256 VLANs aufspannen will, ist tatsächlich extrem unwarhscheinlich, selbst für Enthusiasten. Bei einem professionellem Serveranbieter sollte also mindestens das gleiche möglich sein. Aus diesem Grund ist Netcup auch nicht mehr uneingeschränkt zu empfehlen, denn IPv6 ist die Zukunft.

  • es gibt auch noch immer dsl-anbieter bei dennen man keine ipv6 bekommt (ewe tel z.b.)

    fuer alle ohne ipv6, oder für solche die feste ipv6 wollen gibt es noch immer feste ip/48, ip/64 praefixe beim tunnelbroker, inkl. rdns Delegation auf dem eigen dns-server. kostenlos

  • Ich kenne das Problem und löse es aktuell mit Geld. So blöd es klingen mag.

    Business Tarif, statisches /56 und statische v4.


    Das Problem sehe ich vor allem darin, wenn ich mal den Provider wechseln sollte. Die Telekom kann ich halt wenigstens bei einem Tarifwechsel solange ins Kreuz treten, dass ich das Prefix mitnehmen kann. Aber beim Providerwechsel geht das nicht.


    Man stelle sich das mal vor... alle DNS Einträge ändern, rDNS Einträge ändern, ggf. statisch konfigurierte IPs in gewissen Use Cases ändern, Firewall komplett überarbeiten und und und...


    Aber das ist im Endeffekt kein direktes IPv6 Problem. Denn gäbe einem der Provider bei v4 bspw. ein eigenes global geroutetes /24, hätte man das selbe Problem. Und bei IPv4 wurde das Problem (notgedrungener Maßen) mit NAT gelöst. Und wenn man bei IPv6 jetzt halt kein NAT will, bezahlt man gewissermaßen in Unflexibilität.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Das Problem sehe ich vor allem darin, wenn ich mal den Provider wechseln sollte. Die Telekom kann ich halt wenigstens bei einem Tarifwechsel solange ins Kreuz treten, dass ich das Prefix mitnehmen kann. Aber beim Providerwechsel geht das nicht.

    Deswegen würde ich für heimische Serverdienste ein VPN (zB. Wireguard) zu einem Hoster/VPS/Rootserver aufsetzen, wo man ein vernünftiges /56 bekommt und sich dieses durchrouten kann. Dieses ist dann unabhängig vom heimischen Provider. zB. bei den Freunden einer der bekanntesten Skriptsprachen (dem diesjährigen Gewinner des Hosttests in der Kategorie VServer).

  • Das Problem sehe ich vor allem darin, wenn ich mal den Provider wechseln sollte.

    Na ja,

    - wie oft kommt das vor?

    - Warum betreibt man überhaupt den Server am heimischen DSL Anschluss und nicht im Rechenzentrum?

    Man stelle sich das mal vor... alle DNS Einträge ändern, rDNS Einträge ändern, ggf. statisch konfigurierte IPs in gewissen Use Cases ändern, Firewall komplett überarbeiten und und und...

    Wenn tatsächlich so viele Abhängigkeiten an den IPs dran sind, dann sollte man über ein eigenes PI Netz nachdenken.

  • - wie oft kommt das vor?

    Selten, deshalb lebe ich einfach damit.


    - Warum betreibt man überhaupt den Server am heimischen DSL Anschluss und nicht im Rechenzentrum?

    Manche Sachen will man nicht im RZ, sondern unter seinen eigenen Pfötchen haben. Aber das ist halt so ein "Wer A sagt muss auch B sagen"-Ding.


    Und wenn ich bspw. in die Colo gehe und da mein /56 bekomme und in eine Colo bei nem anderen Anbieter umziehe, habe ich das selbe Problem. Aber ich würde behaupten das macht man ungefähr so oft, wie man den Provider wechselt.



    Ich denke halt für mich einen guten Mittelweg mit dem Business Anschluss gefunden zu haben. Nicht zuletzt nutze ich ihn ja auch gewerblich. Und die Telekom freut sich, weil ich mich vor einem Providerwechsel ekel.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber