From: Hannes Laimer <h.laimer@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Stefan Hanreich <s.hanreich@proxmox.com>
Subject: Re: [pve-devel] [PATCH proxmox-firewall 1/1] fix #6831: move conntrack statement to forward chain
Date: Wed, 1 Oct 2025 09:00:00 +0200 [thread overview]
Message-ID: <36ac861e-e834-45ad-9f50-75e3be31c4f4@proxmox.com> (raw)
In-Reply-To: <20250923122645.154759-1-s.hanreich@proxmox.com>
Could reproduce the problem(s) and this fixes them. The changes also
makes sense, so consider this
Tested-by: Hannes Laimer <h.laimer@proxmox.com>
Reviewed-by: Hannes Laimer <h.laimer@proxmox.com>
On 9/23/25 14:27, Stefan Hanreich wrote:
> The conntrack statement was included in the host-forward chain, which
> is managed by the firewall daemon. It gets flushed in every iteration
> of the daemon, but the rule is never re-created in the daemon. This
> caused conntracked flows that are routed by the PVE host to not get
> accepted. Generally, the ruleset is constructed in a way that all
> chains that are managed by the firewall daemon are empty by default -
> this was the only exception. Move the ct state statement to the
> appropriate chain. Since the forward chain is in the inet table which
> never sees ARP traffic in the first place, remove the respective
> statement matching on ARP. This is most likely copied from the bridge
> table where this modifier is indeed necessary, since there ARP traffic
> is visible.
>
> This also fixes a report from a user in the forum [1], where if the
> daemon fails to generate a ruleset there are growing number of entries
> in the host-forward chain that consists only of the ct state
> statement. This is because the host-forward chain never gets flushed
> by the default ruleset, but nftables inserts all rules in the chain an
> additional time when executing the default ruleset.
>
> [1] https://forum.proxmox.com/threads/macro-firewall-rules-not-working-with-nftables.171262/#post-799600
>
> Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
> ---
> proxmox-firewall/resources/proxmox-firewall.nft | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/proxmox-firewall/resources/proxmox-firewall.nft b/proxmox-firewall/resources/proxmox-firewall.nft
> index 2456336..ea102ec 100644
> --- a/proxmox-firewall/resources/proxmox-firewall.nft
> +++ b/proxmox-firewall/resources/proxmox-firewall.nft
> @@ -267,6 +267,7 @@ table inet proxmox-firewall {
>
> chain forward {
> type filter hook forward priority filter; policy accept;
> + ct state vmap { established : accept, related : accept, invalid : jump invalid-conntrack }
> jump host-forward
> jump cluster-forward
> }
> @@ -278,9 +279,7 @@ table inet proxmox-firewall {
> chain host-out {}
>
> chain cluster-forward {}
> - chain host-forward {
> - meta protocol != arp ct state vmap { established : accept, related : accept, invalid : jump invalid-conntrack }
> - }
> + chain host-forward {}
>
> chain ct-in {}
> chain invalid-conntrack { }
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-10-01 7:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 12:26 Stefan Hanreich
2025-10-01 7:00 ` Hannes Laimer [this message]
2025-10-04 12:58 ` [pve-devel] applied: " Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36ac861e-e834-45ad-9f50-75e3be31c4f4@proxmox.com \
--to=h.laimer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.hanreich@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.