I forgot to add this in my previous mail, please also include the current versions you are running:
$ pveversion -v On 2/2/26 7:06 PM, Stefan Hanreich wrote: > Tried to quickly reproduce this on a test cluster but couldn't confirm > the behavior. Could you send me the full output of the following > commands (you can mail me the information directly) when the firewal is > *not* working. Note that some of the commands have placeholders (NODE > being the node where the issue occurs, VMID being the VM where the issue > occurs). > > > Firewall config : > > $ cat /etc/pve/firewall/cluster.fw > $ cat /etc/pve/nodes/<NODE>/cluster.fw > $ cat /etc/pve/firewall/<VMID>.fw > > VM configuration: > > $ qm config <VMID> --current > > Current status of network config: > > $ ip a > > $ cat /etc/network/interfaces > $ cat /etc/network/interfaces.d/sdn > > compiled firewall output: > > $ iptables-save -c > $ nft list ruleset > > syslogs: > > $ journalctl --since '2026-02-01' -u pve-firewall > $ journalctl --since '2026-02-01' -u proxmox-firewall > > > > We have a specific channel dedicated for reporting security issues [1], > so for any future security reports please utilize this one instead of > the pve-user mailing list! > > [1] https://pve.proxmox.com/wiki/Security_Reporting > > > On 2/2/26 6:32 PM, W3Net Admin wrote: >> Hello, >> >> I have Identified a security bug at the DC firewall level where firewall >> rules are bypassed. I am concerned that this could be a zero day >> vulnerability. Based on the conditions below, any security group, in this >> case sg_pbs_stor_pbs is an empty group with NO rules, will hijack the >> traffic flow and stop FW filtering. If the drop rule was placed above >> security groups then it worked as expected. My test was pinging my host from >> a VM, the drop rule should have stopped the ping but if the vm was on the >> same host, the ping was acknowledged >> >> >> This happens in a very specific scenario, the conditions to recreate are: >> >> 1. VM Must be running on its Host, this does not affect VM running on a >> different host. >> 2. A vlan based vnet is created and tagged >> 3. The host gets a static IP on the vnet >> 4. Default Input Policy: Drop >> >> nano /etc/pve/firewall/cluster.fw >> [group sg_pbs_stor_pbs] # PBS Rules #<-Empty Group, no rules >> >> [RULES] >> >> GROUP sg_pbs_stor_pbs -i vmbr1.2 #<-This will steal the traffic flow and >> processing will stop >> IN DROP -i inf0nas -log nolog #<- it never makes it here >> >> /etc/network/interfaces.d/sdn >> auto inf0nas >> iface inf0nas >> bridge_ports vmbr1.14 >> bridge_stp off >> bridge_fd 0 >> mtu 9000 >> alias NAS >> >> /etc/network/interfaces >> auto vmbr1 >> iface vmbr1 inet manual >> bridge-ports enp12s0f0np0 >> bridge-stp off >> bridge-fd 0 >> bridge-vlan-aware yes >> bridge-vids 1-100 >> mtu 9000 >> >> auto inf0nas #<- notice the use of a vnet >> iface inf0nas inet static >> address 10.32.14.111/24 >> mtu 9000 >> >> >> Thanks, >> W3Net Admin >> >> >> >
