From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 07EA91FF165 for <inbox@lore.proxmox.com>; Wed, 12 Mar 2025 13:51:42 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8BAE34AC1; Wed, 12 Mar 2025 13:51:32 +0100 (CET) Message-ID: <578b7f6c-376e-4ff0-8a92-99e443e031c0@proxmox.com> Date: Wed, 12 Mar 2025 13:51:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Hannes Laimer <h.laimer@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250220151401.16555-1-h.laimer@proxmox.com> <3d4e2386-2ba5-4460-9eef-13a80da695cf@proxmox.com> <2e127582-005d-40fd-bf01-0c16586c4ba0@proxmox.com> Content-Language: en-US From: Stefan Hanreich <s.hanreich@proxmox.com> In-Reply-To: <2e127582-005d-40fd-bf01-0c16586c4ba0@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.679 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_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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. [proxmox.com] Subject: Re: [pve-devel] [PATCH proxmox-firewall 1/2] fix: firewall: apply `nt_conntrack_allow_invalid` to all chains 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> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> On 3/12/25 11:18, Hannes Laimer wrote: > On 3/4/25 13:24, Stefan Hanreich wrote: >> default-in is also checking for conntrack status, so we should put this > > I think `default-in` is currently noop'ing[1] ct state invalid, am I > missing something? I though maybe there's a reason for that, so I > left it as is, as with the change we'd drop there with invalid ct > state. Yes, it is - I think I also remember the reason now for not including invalid initially. CT has issues with multicast / broadcast traffic, since it is impossible to know the return IP. We had some issues with DHCP on bridges with firewall-enabled guests for instance. There are workarounds / solutions for this (ICMPv6 has explicit exceptions in the conntrack module for instance, some protocols have conntrack helpers), but they're not a silver bullet that work for every conceivable protocol. There were some additional fixes in the kernel for this in the meanwhile [1]. The old firewall does drop invalid CT traffic going in / out the host unless the nt_conntrack_allow_invalid setting is set: -A PVEFW-HOST-IN -m conntrack --ctstate INVALID -j DROP -A PVEFW-HOST-IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT [...] -A PVEFW-HOST-OUT -m conntrack --ctstate INVALID -j DROP -A PVEFW-HOST-OUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT Same for guest traffic: -A PVEFW-FORWARD -m conntrack --ctstate INVALID -j DROP -A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT IMO we should explicitly check for CT state invalid everywhere we are checking CT state, since dropping it at some place but not the other seems wrong/inconsistent. I'd also definitely default to dropping invalid traffic everywhere, unless explicitly disabled by the user. I think it's best for now to stick to what the old firewall is doing? It should have the same effect in the new firewall, and we don't really have lots of reports of this behavior causing issues. For users that *are* encountering issues with this behavior, we have an escape hatch with nt_conntrack_allow_invalid, which is okay IMO since that doesn't bypass the firewall (all invalid packets still go through the ruleset and get either accepted / dropped according to the ruleset). It only hurts performance for that connection and consumes some CPU cycles. We need to rework how we are utilizing CT in the near future though. It would be nice to implement support for notrack [2] in the firewall, which would help users to handle this more surgically by explicitly exempting certain connections from conntrack. For EVPN we also need to revisit CT handling of the firewall. So this is something that's on the roadmap anyway. [1] https://lore.kernel.org/lkml/ZfyeC8mjLnGkqnVT@calendula/t/#m32cb12199c69a77f14786ec17b2df8566f34fe95 [2] https://bugzilla.proxmox.com/show_bug.cgi?id=2441 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel