From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 7B9CD90D8E for ; Tue, 2 Apr 2024 23:13:01 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 55791E21B for ; Tue, 2 Apr 2024 23:12:31 +0200 (CEST) Received: from 8.mo548.mail-out.ovh.net (8.mo548.mail-out.ovh.net [46.105.45.231]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 2 Apr 2024 23:12:30 +0200 (CEST) Received: from mxplan7.mail.ovh.net (unknown [10.108.2.90]) by mo548.mail-out.ovh.net (Postfix) with ESMTPS id 4V8Kh46RGFzyjG for ; Tue, 2 Apr 2024 20:47:32 +0000 (UTC) Received: from guerby.net (37.59.142.105) by DAG3EX1.mxp7.local (172.16.2.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Tue, 2 Apr 2024 22:47:32 +0200 Authentication-Results: garm.ovh; auth=pass (GARM-105G0065bce1b99-ad97-478d-8513-ae0aeba5a035, 462617303963BE1B71ED2E878694509AE893540A) smtp.auth=laurent@guerby.net X-OVh-ClientIp: 91.224.148.165 Message-ID: From: Laurent GUERBY To: Proxmox VE development discussion Date: Tue, 2 Apr 2024 22:47:31 +0200 In-Reply-To: <20240402171629.536804-1-s.hanreich@proxmox.com> References: <20240402171629.536804-1-s.hanreich@proxmox.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Originating-IP: [37.59.142.105] X-ClientProxiedBy: DAG7EX1.mxp7.local (172.16.2.61) To DAG3EX1.mxp7.local (172.16.2.21) X-Ovh-Tracer-GUID: 4ab7e1df-8126-4b33-8591-5448bc8ffdd6 X-Ovh-Tracer-Id: 7990511641424698903 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrudefvddgudehvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepkffuhffvffgjfhgtgfgfgghisehtqhertddtreejnecuhfhrohhmpefnrghurhgvnhhtucfifgfgtfeujgcuoehlrghurhgvnhhtsehguhgvrhgshidrnhgvtheqnecuggftrfgrthhtvghrnheptedtudeugeevheefueejieeghfffgfeltdefteevffetgedtkeefueeilefftedvnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutdehpdeluddrvddvgedrudegkedrudeiheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomheplhgruhhrvghnthesghhuvghrsgihrdhnvghtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepphhvvgdquggvvhgvlheslhhishhtshdrphhrohigmhhogidrtghomhdpoffvtefjohhsthepmhhoheegkedpmhhouggvpehsmhhtphhouhht X-SPAM-LEVEL: Spam detection results: 0 AWL 0.200 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 RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2024 21:13:01 -0000 On Tue, 2024-04-02 at 19:15 +0200, Stefan Hanreich wrote: >=20 > ## Known Issues > There is currently one major issue that we still need to solve: REJECTing > packets from the guest firewalls is currently not possible for incoming t= raffic > (it will instead be dropped). >=20 > This is due to the fact that we are using the postrouting hook of nftable= s in a > table with type bridge for incoming traffic. In the bridge table in the > postrouting hook we cannot tell whether the packet has also been sent to = other > ports in the bridge (e.g. when a MAC has not yet been learned and the pac= ket > then gets flooded to all bridge ports). If we would then REJECT a packet = in the > postrouting hook this can lead to a bug where the firewall rules for one = guest > REJECT a packet and send a response (RST for TCP, ICMP port/host-unreacha= ble > otherwise). >=20 > This has also been explained in the respective commit introducing the > restriction [1]. >=20 > We were able to circumvent this restriction in the old firewall due to us= ing > firewall bridges and rejecting in the firewall bridge itself. Doing this = leads > to the behavior described above, which has tripped up some of our users b= efore > [2] [3] and which is, frankly, wrong. >=20 > I currently see two possible solutions for this, both of which carry down= sides. > Your input on this matter would be much appreciated, particularly if you = can > think of another solution which I cannot currently see: >=20 > 1. Only REJECT packets in the prerouting chain of the firewall bridge wit= h the > destination MAC address set to the MAC address of the network device, oth= erwise > DROP >=20 > The downside of this is that we, once again, will have to resort to using > firewall bridges, which we wanted to eliminate. This would also be the so= le > reason for still having to resort to using firewall bridges. >=20 > 2. Only allow DROP in the guest firewall for incoming traffic >=20 > This would be quite awkward since, well, rejecting traffic would be quite= nice > for a firewall I'd say ;) >=20 > I'm happy for all input regarding this matter. Hi, REJECT is a L3 IP feature, to implement it properly in all cases your firewall rule needs to know both about IP adresses involved (and the corresponding MAC too in the ethernet case).=20 I don't currently use the proxmox VE firewalling capabilities (I was waiting for nftables to look at it :) but may be a compromise would be to warn during the transition from iptables to nftables (or from version N to N+1) that if a REJECT rule is found without explicit IP and MAC that it will just be transformed to DROP, and if the user wants a REJECT the user needs to add explicit IP and MAC pairs.=C2=A0 Then the Promox VE firewalling can be done in "ip" tables which know how to match ether MAC ("type ipv4_addr . ether_addr" to match both IP and MAC at the same time) and no firewall bridge needed. Sincerely, Laurent GUERBY