From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <s.hanreich@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 20F7D90EBD for <pve-devel@lists.proxmox.com>; Wed, 3 Apr 2024 09:52:34 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id EF691134C4 for <pve-devel@lists.proxmox.com>; Wed, 3 Apr 2024 09:52:03 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Wed, 3 Apr 2024 09:52:03 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 2200041662 for <pve-devel@lists.proxmox.com>; Wed, 3 Apr 2024 09:52:03 +0200 (CEST) Message-ID: <4a72b3ed-4bba-45f9-945a-7f64230947b4@proxmox.com> Date: Wed, 3 Apr 2024 09:52:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: pve-devel@lists.proxmox.com References: <20240402171629.536804-1-s.hanreich@proxmox.com> <mailman.54.1712122640.450.pve-devel@lists.proxmox.com> Content-Language: en-US From: Stefan Hanreich <s.hanreich@proxmox.com> In-Reply-To: <mailman.54.1712122640.450.pve-devel@lists.proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.590 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [RFC container/firewall/manager/proxmox-firewall/qemu-server 00/37] proxmox firewall nftables implementation X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Wed, 03 Apr 2024 07:52:34 -0000 On 4/3/24 07:37, DERUMIER, Alexandre via pve-devel wrote: > I'll really take time to test it (I was super busy theses last month > with a datacenter migration), as I wait for nftables since a while. > > Can't help too much with rust, but I really appriciate it, as I had > some servers with a lot of vms && rules, take more than 10s to generate > the rules with current perl implementation). Thanks! I'd be really interested in how this performs with a large ruleset since I haven't really tried with an excessively large ruleset so far. I have only done very basic checks of the performance, but it looked quite promising. 50% of the time is actually spent in libnftables, so I'd be interested to see how this changes with large rulesets. There is also still some room for performance improvements, since performance wasn't my main concern so far. For instance I am currently reading the guest configuration files 1:1 via the filesystem, but I wanted to implement getting the configuration via pmxcfs where one call would then suffice to retrieve the network configuration of all guests. If you have a large configuration I could use for testing, that you'd be willing to share, then I could run tests myself. Otherwise I will probably use a script to generate a huge config myself at some point. > I really would like to not have fwbr bridge anymore, because I have > seen a big performance bug with them: I agree 100%, getting rid of those would eliminate several bugs and issues. > I'll try your code, see the generated rules, and try to see if I can > get reject working. Thanks! Maybe you can come up with something. Otherwise we might have to implement a configuration option that switches between firewall bridge on/off and people have to make choices about the tradeoffs themselves.