[pve-devel] pve-firewall : nftables ?

[Wolfgang Bumiller]

On Mon, Nov 26, 2018 at 09:00:47AM +0100, Alexandre DERUMIER wrote:
> Hi,
> 
> I would like to known if somebody have already made some test with nftables recently ?
> 
> Mainly, is not possible to use physdev direction,
> 
> like:
> 
> -A PVEFW-FWBR-OUT -m physdev --physdev-in tap160i1 --physdev-is-bridged -j tap160i1-OUT
> 
> 
> I wonder if a simple vmap like this could work: ?
> 
> https://wiki.nftables.org/wiki-nftables/index.php/Classic_perimetral_firewall_example
> 
> 
> chain forward {
>         type filter hook forward priority 0; policy drop;
>         jump global
>         oifname vmap { $nic_dmz : jump dmz_in , $nic_lan : jump lan_in }
>         oifname $nic_inet iifname vmap { $nic_dmz : jump dmz_out , $nic_lan : jump lan_out }
> }

The issue was that the regular filter forward table isn't really used
for bridged traffic (IIRC?), while the bridge filter forward table
doesn't have access to conntrack. There may be other ways (at some
point I marked packets in the netdev tables), but I haven't checked in
a while.
At least I haven't produced any kernel crashes in a while ;-D

IIRC the issue with netdev tables on the other hand was that they'd have
to be created after a network device was created. Can't have them "wait
around" for the device. (Not a big deal, just needs a little more
callbacks in our interface creation code and lxc bridge hook.) I'd want
source mac & ip checks to be moved to those tables for outgoing
packets, they happen quite early in the stack.

The pve-firewall code is very iptables-oriented though, and I'm not sure
if maybe we're not better off splitting the rule-generating part out
and write the nftables variant from scratch... The iptables part would
be considered feature-frozen from that point on I'd say/hope/think...