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 C211490F0D
for <pve-devel@lists.proxmox.com>; Wed, 3 Apr 2024 09:33:33 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 9434E12F81
for <pve-devel@lists.proxmox.com>; Wed, 3 Apr 2024 09:33: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:33:01 +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 0ED7C44C75
for <pve-devel@lists.proxmox.com>; Wed, 3 Apr 2024 09:33:01 +0200 (CEST)
Message-ID: <8c37186a-ddfd-4f33-b638-de0cc51daf18@proxmox.com>
Date: Wed, 3 Apr 2024 09:33:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: pve-devel@lists.proxmox.com
References: <20240402171629.536804-1-s.hanreich@proxmox.com>
<c96ab1b3b900f3f6aca02dadf343bc35b928a653.camel@guerby.net>
Content-Language: en-US
From: Stefan Hanreich <s.hanreich@proxmox.com>
In-Reply-To: <c96ab1b3b900f3f6aca02dadf343bc35b928a653.camel@guerby.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.592 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
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [nftables.org]
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:33:33 -0000
On 4/2/24 22:47, Laurent GUERBY wrote:
> 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).
Yes indeed, although we have L3 and L4 information available in the
bridge table, otherwise REJECT would also be impossible in the
prerouting / input hooks. REJECTing in the bridge table simply sends a
packet with source and destination IP of the initial packet flipped [1].
Nevertheless, we cannot tell whether the destination IP address in the
packet is actually the IP address of the guest (in the case of VMs) -
even if the MAC address is from the guest. So we might need to combine
this with the ipfilter ipsets if we want to make sure to only send
REJECTs with IP addresses that are actually configured in the guest.
> 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.
See my point above regarding ipfilters.
> 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.
Host firewalling is already done in the inet tables (which is ip + ip6),
but for guest firewalling we will have to use the bridge table one way
or another, since it is the only viable hook for handling the guest
traffic (see [2]), which usually runs via bridges.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/ipv4/netfilter/nf_reject_ipv4.c?h=v6.8.2#n168
[2] https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks