Allow user-defined nftables chains to override Proxmox firewall drops within the same hook

[cmoralesr]

Environment​

• Proxmox VE version: 9.x (nftables backend enabled)
• Firewall backend: nftables
• Affected components: proxmox-firewall, nftables chain evaluation order

Description​

When using the Proxmox VE firewall with nftables, multiple base chains per hook (input, forward, output) are created at different priorities.
Under current Netfilter semantics, a verdict of accept inside a base chain does not terminate processing for that hook; evaluation continues into subsequent base chains with higher priority. As a result, any drop rule or restrictive default policy inside a later PVE-generated chain will override an earlier accept in a user-defined chain.

This prevents administrators from reliably “whitelisting” traffic before Proxmox’s own firewall rules without disabling or rewriting large portions of the built-in firewall.

Steps to Reproduce​

1. Create a user-defined base chain on the input hook with lower priority (e.g., prio -5) and add an accept rule for a specific source IP.
2. Leave the Proxmox firewall enabled with its default drop policy on the input hook at prio 0.
3. Send traffic from the whitelisted source.

Traffic is dropped by the PVE firewall chain even though it was accepted in the earlier custom chain.
Traffic explicitly accepted in a user-defined chain should not be overridden by later PVE firewall drops unless explicitly configured.

Impact​

• Reduces flexibility for advanced users who need both the PVE firewall and custom nftables rules to coexist.
• Forces workarounds like custom systemd units or disabling the PVE firewall entirely for certain nodes, increasing complexity and risk.

Proposed Solutions​

• Provide an option to mark user-defined chains as “final,” stopping evaluation after accept.
• Alternatively, allow configuration of chain ordering or default policies so custom accept rules can safely take precedence.

Additional Notes​

This request aligns with community feedback on needing more control over rule evaluation order when mixing Proxmox-generated and custom nftables rules.

 

[shanreich]

Please try to avoid using LLMs to create your posts, it usually makes them harder to read and potentially introduces subtle mistakes.

Provide an option to mark user-defined chains as “final,” stopping evaluation after accept.

This is not possible with how nftables works, you cannot mark an accept as final - it will always evaluate all subsequent chains in the ruleset.

Alternatively, allow configuration of chain ordering or default policies so custom accept rules can safely take precedence.

Same reason as above, drops are final to the whole ruleset - accepts are only final to the current chain.

A potential solution I see here is defining a specific mark that users can set in their custom chains that precede proxmox-firewall chains (e.g. [1]) and then adding a rule in the firewall-generated ruleset that automatically accepts all traffic with a certain mark thus bypassing the proxmox-firewall ruleset. If possible could you create a feature request in our Bugzilla? [2].

[1] https://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_metainformation#packet_mark
[2] https://bugzilla.proxmox.com/

 

[cmoralesr]

Hi Stefan,

I've implemented an ACCEPT override exclusively for the input chain because I needed to block certain default ports, such as Corosync, for testing purposes. This approach worked for our immediate needs.

However, since Proxmox refreshes the firewall rules every 5 seconds, I was hoping for one of the following capabilities:

1. Proxmox-Firewall Hook – A supported method to inject a custom, full nftables ruleset within the Proxmox-generated rules are applied.
   
   
2. Mark-Based Bypass – The ability to use packet marks (e.g., ACCEPT ct mark …) so that marked packets are consistently accepted before Proxmox rules, even after rule refreshes. As far as I can tell, there is currently no documented way to achieve this through the .fw files.

As a workaround, I changed the input policy to ACCEPT and applied my own priority-based rules instead of relying on the GUI input filters In sacrifice that now no GUI changes really take effect on nftables (Expected and known).

Could you confirm whether it makes sense for me to open a feature request in Bugzilla for this, or if there is already a supported mechanism that I might have overlooked?

Thank you,
Carlos M.