From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <laurent@guerby.net>
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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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: <c96ab1b3b900f3f6aca02dadf343bc35b928a653.camel@guerby.net>
From: Laurent GUERBY <laurent@guerby.net>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
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 <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: 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