[PVE-User] PVE-firewall and multicast with linux bridging

[Bryan Fields]

On 6/30/25 2:16 AM, g.husson_proxmox-pve-user--- via pve-user wrote:
> "It is not a bug, it is a feature" :-)
> Look at the documentation :
> ===
> The following traffic is dropped, but not logged even with logging enabled:
> - Broadcast, multicast and anycast traffic not related to corosync, 
> i.e., not coming through ports 5405-5412
> ===
> 
> Again, from the documentation :
> ===
> proxmox-firewall will create two tables that are managed by the proxmox- 
> firewall service: proxmox-firewall and proxmox-firewall-guests. If you 
> want to create custom rules that live outside the Proxmox VE firewall 
> configuration you can create your own tables to manage your custom 
> firewall rules. proxmox-firewall will only touch the tables it 
> generates, so you can easily extend and modify the behavior of the 
> proxmox-firewall by adding your own tables.
> ===

None of this mentions that connection tracking is enabled globally, even 
on interfaces that are not firewalled.  It's an undocumented "feature".

This kills multicast traffic globally, and owing to connection tracking 
being unable to match traffic.

> Chain PVEFW-FORWARD (1 references)
> num  target     prot opt source               destination
> 1    DROP       0    --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID

> Now you can use rc.local, or crontab @reboot or better a systemd file 
> that chains after proxmox VE firewall start in order to apply the manual 
> rules you found.

Given how iptables works, I can make a new table and insert it before 
the PVEFW-FORWARD chain.  However there is no way to negate a later rule 
other than by allowing/forwarding it, which I may not want to do 'permit 
any any' on an interface globally.   The only option is to edit the 
PVEFW-FORWARD chain directly, but this will get overwritten on reboots 
and when the firewall settings are changed in pve.

If there's a way to kick off a script when pve-firewall updates, this 
would be an option, but the better option would be to fix this so it can 
be enabled on a per interface basis, rather than all or none.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net