>>sysctl net.bridge.bridge-nf-call-iptables=1 >>(don't have tested more than this, but i'm seeing vm connections in >>conntrack)
Damned, don't work because all is going to ip filter, and tap interface are physin/physout in this case (and physdev is not supported by nftables) :/ ----- Mail original ----- De: "aderumier" <[email protected]> À: "pve-devel" <[email protected]> Envoyé: Mercredi 28 Novembre 2018 06:57:27 Objet: Re: [pve-devel] pve-firewall : nftables ? >>Also, >>it seem than conntrack is not yet implemented on bridge filtering :( >> >>seem to be a blocking point for now I have send a mail to the guy from the paper, devs are currently working on bridge conntrack. for now, it's possible to use a workaround, with sysctl net.bridge.bridge-nf-call-iptables=1 then, something like this seem to work: nft add table bridge filter nft add chain bridge filter forward { type filter hook forward priority 0 \; } nft add rule bridge filter forward log nft add table filter nft add chain filter forward { type filter hook forward priority 0 \; } nft add rule filter forward ct state established,related counter accept (don't have tested more than this, but i'm seeing vm connections in conntrack) ----- Mail original ----- De: "aderumier" <[email protected]> À: "pve-devel" <[email protected]> Envoyé: Mardi 27 Novembre 2018 16:55:50 Objet: Re: [pve-devel] pve-firewall : nftables ? Also, it seem than conntrack is not yet implemented on bridge filtering :( seem to be a blocking point for now ----- Mail original ----- De: "Alexandre Derumier" <[email protected]> À: "Wolfgang Bumiller" <[email protected]> Cc: "pve-devel" <[email protected]> Envoyé: Mardi 27 Novembre 2018 15:19:41 Objet: Re: [pve-devel] pve-firewall : nftables ? > >>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 I have found an interesting paper from netdevconf 1.1 here: https://www.netdevconf.org/1.1/proceedings/papers/Bridge-filter-with-nftables.pdf I'll to do some tests in coming week. >>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... yes, indeed. could be better to rewrite it from stratch. (and maybe better than iptables, with all the new features like vmap,...) >>The iptables part would be considered feature-frozen from that point on I'd >>say/hope/think... Still missing some log features. (Currently I can't have any log on an accept/reject rule) ----- Mail original ----- De: "Wolfgang Bumiller" <[email protected]> À: "Alexandre Derumier" <[email protected]> Cc: "pve-devel" <[email protected]> Envoyé: Mardi 27 Novembre 2018 14:55:52 Objet: Re: [pve-devel] pve-firewall : nftables ? 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... _______________________________________________ pve-devel mailing list [email protected] https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list [email protected] https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list [email protected] https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel _______________________________________________ pve-devel mailing list [email protected] https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
