[Debienna] firehol -> nftables

[reox]

Bei A1 funktioniert v6 ohne extra ppp, ich hole mir per dhcpv6c eine IP 
fürs Interface ab und einen prefix, welcher dann per radvd verteilt 
wird. Das hab ich hier auch mal dokumentiert: 
https://www.reox.at/apu1c/a1ipv6/

Naja brauchen - nein, einen Anwendungsfall habe ich nicht wirklich - 
zumal die Prefixe alle x Tage wechseln (es sind nicht 31, so wie bei v4 
aber alle paar Zwangsdisconnects bekomme ich einen neuen).
Aber was man hat, hat man, oder?

den IRC kenne ich aber ich bin gar nicht mehr unterwegs...

LG Sebastian


Am 09.01.2025 um 11:14 schrieb Lukas Matasovsky via Debienna:
> 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 at 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 at lists.metalab.at
>> https://lists.metalab.at/mailman/listinfo/debienna
> 
> _______________________________________________
> Debienna mailing list
> Debienna at lists.metalab.at
> https://lists.metalab.at/mailman/listinfo/debienna