Hi! Cool, danke! Das schaut tatsächlich ähnlich zu firehol aus. Werde mich damit - und auch der nativen nftables syntax - näher beschäftigen! LG Sebastian Am 07.01.2025 um 17:34 schrieb Raoul Bhatia:

Ich habe Gutes über https://github.com/FoobarOy/foomuuri/wiki <https:// github.com/FoobarOy/foomuuri/wiki> gelesen.

Aktuell verwende ich es aber (noch) nicht.

LG, Raoul -- DI (FH) Raoul Bhatia MSc E-Mail. raoul@bhatia.at Tel. +43 699 10132530 -------------------------------------------------------------------------------- *From:* reox via Debienna <debienna@lists.metalab.at> *Sent:* Tuesday, 7 January 2025 09:54 *To:* debienna@lists.metalab.at *Cc:* reox *Subject:* [Debienna] firehol -> nftables

Hi!

Ich plane meinen heimischen Router von firehol auf nftables zu ändern. Hat jemand das hier schon mal gemacht und hat ein paar Tipps? Insbesondere: Nimmt man heute überhaupt Plain-nftables? Firewalld wird oft empfohlen (zB auch im Debian Wiki) aber XML-Configs finde ich nicht schön... (Ja, ich kenne Elektra ;))

Insbesondere was die "router" und IPv4/v6 dual Stack angeht verstehe ich das Prozerdere bei nftables noch nicht so ganz. Das nftables Wiki ist auch nicht so hilfreich, da dort meines Erachtens immer wieder andere Varianten gezeigt werden, die aber irgendwie nirgends erklärt werden. Eine dual Stack Konfiguration (idealerweise von A1 mit PPPoE) als Referenz würde mir vermutlich auch mal helfen!

LG Sebastian

_______________________________________________ Debienna mailing list Debienna@lists.metalab.at https://lists.metalab.at/mailman/listinfo/debienna

Hi! Also zum Hintergrund: ich hab A1 und dort muss man zunächst im VLAN 2 sein und kann dann dort PPPoE starten. Ich erhalte eine public v4 Adresse und ein /64 v6 Prefix (Anm.: Ich hab schon bei A1 gefragt ob sie nicht /56 hergeben, aber das geht laut ihnen nicht...). Auf dem Router rennt nach außen hin offen nur ein Wireguard und SSH ist bestimmten src-IPs erlaubt. Intern gibt es mehrere VLANs und als Dienste DHCP & DNS (sowie SSH). Einzige "Spezialkonfiguration" ist ein VLAN, aus dem nur ein Host routen darf und in das es aus einem anderen VLAN routen gibt. Die firehol funktioniert seit eh und je gut und ich hab damit eigentlich keine Probleme. Jedoch wird mittlerweile nftables empfohlen und ist in neuen systemen als default aktiv und ich wollte mich damit einfach beschäftigen. Der Start erscheint mir noch etwas steiler zu sein als mit iptables - vielleicht ist das aber auch nur mein Eindruck. Ich hatte mir ein Ruleset zusammengezimmert, wo ich glaubte das zumindest v4 Routing gehen sollte - aber da tat sich gar nichts. Also hab ich wieder die Firehol aktiviert ;) (Das Blöde ist, wenn man das am Produktivsystem testen muss, so kann ich das nur machen wenn sonst keiner das Internet braucht...) LG Sebastian Am 08.01.2025 um 05:14 schrieb Sascha Reißner via Debienna:

Hi Sebastian,

dazu wäre auch interessant was Du machen willst. Also ich lese nur herraus, dass Du eine Einwahlverbindung hast. Klassisch mit einer dynamischen IP oder einer/mehrere fixe IPs? willst Du Dienste anbieten oder zumindest von aussen via SSH rein, oder soll gar nichts rein?

Ich selber arbeite seit über 15 Jahren mit iptables und das funktioniert immer noch. Ich glaub da gibt es eine Rückwertskompatibilität. Hab dazu selber ein init-Script geschrieben (/etc/init.d/ipfilter) und 2 Configs. Eine, die die Interfaces und Netzwerke beschreiben und eine mit den Regeln.

Dieses Script läuft an mehreren Standorten mit unterschiedlicher Konfiguration.

Was es nicht kann ist zwischen mehreren internen Netzen filtern. Mein Grundgedanke war, das innere Netz von Aussen zu schützen. Ist aber durch Anpassungen auch sicher möglich zwischen internen Netzen (DMZ?) zu differieren.

Ah, und IPv6 hab ich noch nicht wirklich was gemacht. Aber ich schätze wenn man die Befehle iptables gegen ip6tables austauscht, bekommt man auch schnell etwas funktionierendes.

Wenn Du (oder wer Anderer) Interesse daran hat, such ich die letzte Version mal raus.

Am Dienstag, dem 07.01.2025 um 09:54 +0100 schrieb reox via Debienna:

...

Hi!

Ich plane meinen heimischen Router von firehol auf nftables zu ändern. Hat jemand das hier schon mal gemacht und hat ein paar Tipps? Insbesondere: Nimmt man heute überhaupt Plain-nftables? Firewalld wird oft empfohlen (zB auch im Debian Wiki) aber XML-Configs finde ich nicht schön... (Ja, ich kenne Elektra ;))

Insbesondere was die "router" und IPv4/v6 dual Stack angeht verstehe ich das Prozerdere bei nftables noch nicht so ganz. Das nftables Wiki ist auch nicht so hilfreich, da dort meines Erachtens immer wieder andere Varianten gezeigt werden, die aber irgendwie nirgends erklärt werden. Eine dual Stack Konfiguration (idealerweise von A1 mit PPPoE) als Referenz würde mir vermutlich auch mal helfen!

LG Sebastian

_______________________________________________ Debienna mailing list Debienna@lists.metalab.at https://lists.metalab.at/mailman/listinfo/debienna

_______________________________________________ Debienna mailing list Debienna@lists.metalab.at https://lists.metalab.at/mailman/listinfo/debienna

Ich hab bei A1 mehrfach wegen dem Präfix nachgefragt - ne ganz interessante Geschichte, daher schreib ich mal OT: Zuerst hab ich beim normalen first level Support angerufen und gefragt ob sie nicht auch ein /56 hergeben wollen. Ich habe VLANs im LAN und möchte gerne jedem ein eigenes Präfix delegieren. Der Mitarbeiter meinte sofort "Klar ist das Möglich, ich schalte ihnen das sofort frei". Ich hab zwei Tage gewartet und den dhcpv6c und das ppp mehrfach neu gestartet - aber bekam immer nur das bekannte /64. Hab alle Optionen bzgl Prefix ausprobiert, es gibt ja zB eine um den DHCP nach einer gewissen Länge zu fragen... Dann nochmal angerufen. Es hieß dann "ja komisch, sehen wir hier auch nicht, aber ich frag mal". Nach ein paar Minuten dann "na das sollte freigeschalten sein, ich hab es jetzt aber nochmal gemacht". Allerdings passierte wieder nix... Also nochmal angerufen. Der hat dann länger nachgefragt und meinte, ich muss da ein Ticket aufmachen. Hab ich gemeint "ja bitte" - "Die melden sich dann spätestens am Montag". Am Montag sowie der Montag drauf war nichts... Also nochmal angerufen und gesagt ich warte auf den Rückruf wegen dem Ticket... Sagt die mir ernsthaft: "Ich sehe da kein Ticket bei ihnen offen, nicht mal eines geschlossen".... Hab ich gemeint sie sollen jetzt aber wirklich eines aufmachen. Naja gut, diesmal bekam ich sogar eine Nummer. Erstmal passierte dann nichts. Nach ca einer Woche ruft wer an und meint das dauere noch, ich solle mich noch gedulden. Dann wieder ein paar Wochen später ruft mich jemand an. Er war keiner vom Support sondern Techniker oder so (weiß nimmer genau) und er hat das jetzt vom Chef aufs Aug gedrückt bekommen, weiß aber eigentlich gar nicht was er machen soll, daher wollte er mich mal anrufen. Ich erkläre ihm das nochmal mit /56, VLAN, ... Kommt als Antwort "das hab ich noch nie gehört, dass man mehr als /64 braucht (!) weil als Kunde haben sie ja gar nicht so viele Hosts (!! m( !!). Naja noch mehr Erklärerei bzgl wie v6 funktioniert... Jedenfalls hat er sich intern mehrfach erkundigt und die Antwort bekommen, dass Endkunden immer nur ein /64 bekommen. Tjo und das wars dann... Immerhin hat sich jemand um mein Anliegen gekümmert - ist in dem Verein ja auch nicht mehr immer drin... Und ja, ich wollte eh schon zu einem lokalen Wiener Provider wechseln - allerdings hab ich noch eine Bindungsfrist. Aber irgendwann ist auch die aus ;) LG Sebastian Am 13.01.2025 um 09:01 schrieb Sascha Reißner:

Ist bei uns so ähnlich. Nur, dass es bei uns ein anderer Provider ist und wir das VLAN 31 benutzen. Darüber starten wir dann auch eine PPP und beziehen eine IP. Über diese Verbindung werden dann unsere statischen IPs durch geroutet/gereicht. Im übrigen haben wir eine 56-Maske bei IPv6. Genauso ist es auch vorgesehen. Provider bekommen 48er-Masken und die Kunden sollten 56er-Masken bekommen.

Am Mittwoch, dem 08.01.2025 um 08:43 +0100 schrieb reox via Debienna:

...

Hi!

Also zum Hintergrund: ich hab A1 und dort muss man zunächst im VLAN 2 sein und kann dann dort PPPoE starten. Ich erhalte eine public v4 Adresse und ein /64 v6 Prefix (Anm.: Ich hab schon bei A1 gefragt ob sie nicht /56 hergeben, aber das geht laut ihnen nicht...). Auf dem Router rennt nach außen hin offen nur ein Wireguard und SSH ist bestimmten src-IPs erlaubt. Intern gibt es mehrere VLANs und als Dienste DHCP & DNS (sowie SSH). Einzige "Spezialkonfiguration" ist ein VLAN, aus dem nur ein Host routen darf und in das es aus einem anderen VLAN routen gibt.

Die firehol funktioniert seit eh und je gut und ich hab damit eigentlich keine Probleme. Jedoch wird mittlerweile nftables empfohlen und ist in neuen systemen als default aktiv und ich wollte mich damit einfach beschäftigen. Der Start erscheint mir noch etwas steiler zu sein als mit iptables - vielleicht ist das aber auch nur mein Eindruck. Ich hatte mir ein Ruleset zusammengezimmert, wo ich glaubte das zumindest v4 Routing gehen sollte - aber da tat sich gar nichts. Also hab ich wieder die Firehol aktiviert ;) (Das Blöde ist, wenn man das am Produktivsystem testen muss, so kann ich das nur machen wenn sonst keiner das Internet braucht...)

LG Sebastian

Servus, ich würde auch bei nftables bleiben. Ich habe mehrere Standorte/Router und nutze Ansible auch für das Configuration Management von iptables (bin noch nicht auf nftables umgestiegen). Wozu brauchst du IPv6? Hast du zu Hause öffentliche Services laufen und brauchst dafür Adressen? TLS/Certbot auf internen Systemen (das wär vielleicht ein sehr guter Grund generell auf IPv6 umzusteigen wenn da nicht die zero-trust-Abhängigkeiten wären ... ich hab dzt. ein hairpin nat)? Mit FTTH/Fonira hatte ich IPv6 mal mit einem zweiten pppd (einer für IPv4 mit Fixadresse am enp1s0.31, einer für IPv6)  testweise am laufen (die gelieferte Fritzbox liegt seit Anfang an im Kasten ;-)). Konfig vom IPv6 pppd (defaultroute war der IPv4-pppd): --- plugin rp-pppoe.so enp1s0.31 user "USERNAME@fonira.at" ifname fonira6 noipdefault #defaultroute hide-password lcp-echo-interval 0 noauth persist noaccomp default-asyncmap +ipv6 ipv6cp-accept-local debug --- Kennst du OFTC #debian.de ? Hth & Grüße, Lukas On 1/8/25 7:56 PM, ibu--- via Debienna wrote:

On 2025-01-07 09:54, reox via Debienna wrote:

...

Ich plane meinen heimischen Router von firehol auf nftables zu ändern. Hat jemand das hier schon mal gemacht und hat ein paar Tipps? Insbesondere: Nimmt man heute überhaupt Plain-nftables? Firewalld wird oft empfohlen (zB auch im Debian Wiki) aber XML-Configs finde ich nicht schön... (Ja, ich kenne Elektra ;))

Insbesondere was die "router" und IPv4/v6 dual Stack angeht verstehe ich das Prozerdere bei nftables noch nicht so ganz. Das nftables Wiki ist auch nicht so hilfreich, da dort meines Erachtens immer wieder andere Varianten gezeigt werden, die aber irgendwie nirgends erklärt werden. Eine dual Stack Konfiguration (idealerweise von A1 mit PPPoE) als Referenz würde mir vermutlich auch mal helfen!

hi,

ich verwende plain nftables, wo es geht; auf servern, wo libvirt firewalld nutzt, verwende ich in firewalld nftables als backend und kann das, was da rauskommt, dank der unabhängigen tables mit rules mit niedrigerer prio nochmal mit plain nft einschränken (applikationen können so ein stück weit in der firewall config kooperieren). wichtig zu verstehen ist am anfang wohl, dass ein drop und reject final sind, aber ein accept nicht: da werden noch andere tables durchlaufen, soweit vorhanden.

dual stack kannst du soweit wie möglich mit der address family inet abdecken (eine table kann nur rules einer family enthalten; für IPv4 nimm ip, für IPv6 ip6), die rules müssen dann ip oder ip6 spezifizieren. für ipv6 musst du klarerweise neighbor discovery duchlassen, und auch router advertisements wirst du vermutlich nicht verschmähen.

ich häng mal eine reduzierte und editierte nft config von einem system mit externem ppp0 und lan-seitigen lan0 interface und fixer public ip 55.55.55.55 an, wo auch dhcp4 und dhcp6 laufen, ssh rein- und durchgelassen wird, und auch port 80 von einem bestimmten host/netz an einen anderen lan-seitigen host (192.168.0.2) ge-dnat-ted wird (in einer eigenen ipv4 table, in der auch der geforwardete outgoing traffic an public interface ge-snat-ted wird). die zeilen mit nur accept oder drop sind redundant.

zum testen würde ich eine test-umgebung verwenden ;)

vielleicht noch zur entwirrung: die table und chain names sind beliebig, wichtig ist, dass in chains mit bestimmten prios an hooks den paketen auflauern und sie filtern oder modifizieren; das kann in mehreren chains in verschiedenen tables mit unterschiedlichen prios (-> reihenfolge) passieren; die basisinfos sind eigentlich ganz gut auf dieser page zusammengefasst: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks ; die bridge und arp layers (blau und rot) kann du erstmal ignorieren; und welche chain types in welchen address families an welchen hook operieren können, sagt die farbige tabelle.

lg ibu

_______________________________________________ Debienna mailing list Debienna@lists.metalab.at https://lists.metalab.at/mailman/listinfo/debienna

Hi! Vielen Dank! Deine Config liest sich auf jeden Fall einfacher, als das was ich fabriziert habe :D Eine statische v4 hab ich leider nicht, aber so wie ich das verstehe reicht dann auch ein `ip saddr 192.168.0.0/24 oifname "ppp0" masquerade`? Ich glaube was mir beim übersetzen meiner firehol config nach nft schwer fällt ist, dass firehol interfaces und router kennt und ich bei nft nur chains habe, in denen dann dann diese dinge definiert werden. Im nftables wiki war als Beispiel doe Konfiguration mit einzelnen chains pro Interface und dann einer `iifname vmap`. LG Sebastian Am 08.01.2025 um 19:56 schrieb ibu@radempa.de:

On 2025-01-07 09:54, reox via Debienna wrote:

...

Ich plane meinen heimischen Router von firehol auf nftables zu ändern. Hat jemand das hier schon mal gemacht und hat ein paar Tipps? Insbesondere: Nimmt man heute überhaupt Plain-nftables? Firewalld wird oft empfohlen (zB auch im Debian Wiki) aber XML-Configs finde ich nicht schön... (Ja, ich kenne Elektra ;))

Insbesondere was die "router" und IPv4/v6 dual Stack angeht verstehe ich das Prozerdere bei nftables noch nicht so ganz. Das nftables Wiki ist auch nicht so hilfreich, da dort meines Erachtens immer wieder andere Varianten gezeigt werden, die aber irgendwie nirgends erklärt werden. Eine dual Stack Konfiguration (idealerweise von A1 mit PPPoE) als Referenz würde mir vermutlich auch mal helfen!

hi,

ich verwende plain nftables, wo es geht; auf servern, wo libvirt firewalld nutzt, verwende ich in firewalld nftables als backend und kann das, was da rauskommt, dank der unabhängigen tables mit rules mit niedrigerer prio nochmal mit plain nft einschränken (applikationen können so ein stück weit in der firewall config kooperieren). wichtig zu verstehen ist am anfang wohl, dass ein drop und reject final sind, aber ein accept nicht: da werden noch andere tables durchlaufen, soweit vorhanden.

dual stack kannst du soweit wie möglich mit der address family inet abdecken (eine table kann nur rules einer family enthalten; für IPv4 nimm ip, für IPv6 ip6), die rules müssen dann ip oder ip6 spezifizieren. für ipv6 musst du klarerweise neighbor discovery duchlassen, und auch router advertisements wirst du vermutlich nicht verschmähen.

ich häng mal eine reduzierte und editierte nft config von einem system mit externem ppp0 und lan-seitigen lan0 interface und fixer public ip 55.55.55.55 an, wo auch dhcp4 und dhcp6 laufen, ssh rein- und durchgelassen wird, und auch port 80 von einem bestimmten host/netz an einen anderen lan-seitigen host (192.168.0.2) ge-dnat-ted wird (in einer eigenen ipv4 table, in der auch der geforwardete outgoing traffic an public interface ge-snat-ted wird). die zeilen mit nur accept oder drop sind redundant.

zum testen würde ich eine test-umgebung verwenden ;)

vielleicht noch zur entwirrung: die table und chain names sind beliebig, wichtig ist, dass in chains mit bestimmten prios an hooks den paketen auflauern und sie filtern oder modifizieren; das kann in mehreren chains in verschiedenen tables mit unterschiedlichen prios (-> reihenfolge) passieren; die basisinfos sind eigentlich ganz gut auf dieser page zusammengefasst: https://wiki.nftables.org/wiki-nftables/index.php/ Netfilter_hooks ; die bridge und arp layers (blau und rot) kann du erstmal ignorieren; und welche chain types in welchen address families an welchen hook operieren können, sagt die farbige tabelle.

lg ibu