Bug 13198

Summary: client isn’t blocked immediately despite a blocking fw rule
Product: IPFire Reporter: SecCon <dev>
Component: ---Assignee: Michael Tremer <michael.tremer>
Status: CLOSED WONTFIX QA Contact:
Severity: Minor Usability    
Priority: - Unknown - CC: adolf.belka, carlo.fusco, michael.tremer
Version: 2   
Hardware: unspecified   
OS: Unspecified   

Description SecCon 2023-07-29 06:56:25 UTC 
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.
Comment 1 cfusco 2023-07-29 13:44:03 UTC 
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.
Comment 2 Michael Tremer 2023-07-31 13:37:21 UTC 
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.