[pve-devel] [RFC container/firewall/manager/proxmox-firewall/qemu-server 00/37] proxmox firewall nftables implementation

[Laurent GUERBY]

On Tue, 2024-04-02 at 19:15 +0200, Stefan Hanreich wrote:
> 
> ## Known Issues
> There is currently one major issue that we still need to solve: REJECTing
> packets from the guest firewalls is currently not possible for incoming traffic
> (it will instead be dropped).
> 
> This is due to the fact that we are using the postrouting hook of nftables in a
> table with type bridge for incoming traffic. In the bridge table in the
> postrouting hook we cannot tell whether the packet has also been sent to other
> ports in the bridge (e.g. when a MAC has not yet been learned and the packet
> then gets flooded to all bridge ports). If we would then REJECT a packet in the
> postrouting hook this can lead to a bug where the firewall rules for one guest
> REJECT a packet and send a response (RST for TCP, ICMP port/host-unreachable
> otherwise).
> 
> This has also been explained in the respective commit introducing the
> restriction [1].
> 
> We were able to circumvent this restriction in the old firewall due to using
> firewall bridges and rejecting in the firewall bridge itself. Doing this leads
> to the behavior described above, which has tripped up some of our users before
> [2] [3] and which is, frankly, wrong.
> 
> I currently see two possible solutions for this, both of which carry downsides.
> Your input on this matter would be much appreciated, particularly if you can
> think of another solution which I cannot currently see:
> 
> 1. Only REJECT packets in the prerouting chain of the firewall bridge with the
> destination MAC address set to the MAC address of the network device, otherwise
> DROP
> 
> The downside of this is that we, once again, will have to resort to using
> firewall bridges, which we wanted to eliminate. This would also be the sole
> reason for still having to resort to using firewall bridges.
> 
> 2. Only allow DROP in the guest firewall for incoming traffic
> 
> This would be quite awkward since, well, rejecting traffic would be quite nice
> for a firewall I'd say ;)
> 
> I'm happy for all input regarding this matter.

Hi,

REJECT is a L3 IP feature, to implement it properly in all cases your
firewall rule needs to know both about IP adresses involved (and the
corresponding MAC too in the ethernet case). 

I don't currently use the proxmox VE firewalling capabilities (I was
waiting for nftables to look at it :) but may be a compromise would be
to warn during the transition from iptables to nftables (or from
version N to N+1) that if a REJECT rule is found without explicit IP
and MAC that it will just be transformed to DROP, and if the user wants
a REJECT the user needs to add explicit IP and MAC pairs. 

Then the Promox VE firewalling can be done in "ip" tables which know
how to match ether MAC ("type ipv4_addr . ether_addr" to match both IP
and MAC at the same time) and no firewall bridge needed.

Sincerely,

Laurent GUERBY