Greetings, Unsure of categorisation. It seems one has to do some manual labour in order to get a firewall rule blocking a device to actually block it and verify that it is blocked. You have to do any of a number of things, either on the physical client or in IPFire to get a block to work if you need it to work "NOW!". - reset NIC on device - restart IPFire, may not work due to lease time/conn track - clear connection tracking via ssh cmd:\ conntrack -D -s <IP of client> There also seems to be an issue with IPTables not blocking Port 67 Ref: CFUSCO: "Following this rabbit hole, I also found out that IPTABLES does not block UDP port 67 (DHCP): link: https://unix.stackexchange.com/questions/447440/ufw-iptables-not-blocking-dhcp-udp-port-67#447524" For reference I link to the forum thread: https://community.ipfire.org/t/firewall-rule-to-block-a-computer-but-with-some-nuisances/10099 We think it may be reasonable to add a functionality in firewall rules that enables you to actively trigger the equivalent of "conntrack -D -s <IP of client>" when applying a rule, probably when applying it for a single device. May be relevant in other scenarios.
To help clarify the discussion we had on this topic in the community forum, this is my summary. TLDR: Firewall Rule Not Affecting Established Connections A new firewall rule does not immediately affect an already established and tracked connection until a new connection is established by negotiating a new lease with the DHCP server. To resolve this, the established connection can be forced to disconnect using the command: conntrack -D -s <IP of client>. For instance, when blocking access from the green interface to the red interface for a specific IP address, merely creating a new rule will not take effect on existing connections. Question for the Development Team: Should the Web User Interface code be modified to force a new connection in such corner cases? Please disregard me mentioning in that thread the firewall behavior toward a DHCP connection on port 67, it has nothing to do with this report.
Hello, I am not sure what to do with this report. I understand that this is not ideal, however, it is what an SPI firewall does. There is no (easy) way to find any connections that would match such a rule (because we might overmatch since the order of rules matters) and so we cannot reset those connections. I would say, that we will take this onboard for a redesign in IPFire 3, but leave this for now in IPFire 2.