I guess that is how it works, you use rules to open / close connections to / from the network and its diverse segments (I have Blue+Green+Red).
Scenario: a computer on Green, that is not current in regards to OS updates, needs to be blocked until I can deal with it. I create a FW rule, blocking access to Red. Thus it can not access, nor be accessed by, Internet, yet it can still access Green for backups, storage whatever.
From image below
Mac of computer
Standard network selection: Red for Internet access
Drop ( what is the difference between Drop and Reject? I know the difference is in ICMP, but how does it show?)
It is fairly straight forward, but I can think of some nuisances:
The computer won’t be actually disconnected until its session, defined by DHCP server, times out. In my case 3600 minutes, or the computers NIC resets.
Is there no faster way? (EMERGENCY - CUT CONN NOW!) Like pulling the network cable?
Would it not be worth considering adding a “disconnect” functionality to either ARP or DHCP table?
The client dhcp ignores everything from the IPFire server until the lease expires.
The only thing you could do from IPFire is to connect to the client via ssh and then run the clear cache or reboot command. You would have to set up the ssh connection between the client and IPFire.
I think it is not the DHCP lease time. You want give the client an IP whether it is allowed to access the internet. But there are established connections which are allowed, the FW rules inhibits new connections.
Furthermore, web access ( HTTP(S) ) may not go to RED but to the proxy in GREEN. So you should deny this client in squid also.
I wanted to describe the possible problems.
If you don’t use the squid proxy ( disabled? ), then a restart of the firewall should wipe out all existing allowed connections.
I am not sure what you mean here. If you block the IP address of this machine, will not disconnected from RED immediately as soon as you activate the rule and reload the firewall?
The DHCP session needs to timeout before disconnect.
It will of course not be exactly 3600 minutes until timeout, since that depends on how long the session has been active.
There are a couple of ways I can still control this via IPFire and that is , probably, reset the DHCP server by disabling > enabling , or reboot the Firewall.
I do not know what you did there, but if you aimed for disconnecting the computer from the Internet, well that is probably concerning?
That won’t help you because the dhcp server only reacts to dhcp request comms from the client. As long as the client is running with an existing valid lease that still has time to go then it will not change anything.
The first time the client will check with the server will be at 50% of the lease time when it will ask if it is okay to extend the lease time. The server will say no it can’t be extended (because it is no longer valid) so the client will stay with the existing lease until it expires and then it will ask the server for a new lease.
Yes. But this should be a work-around only.
To block a client immediately after activation of the rule, this flushing should be done also.
This should be discussed in the dev team. To initiate, I recommend a ticket in Bugzilla.
BTW: your observation about dependency with DHCP may be a timely coincidence. If a timeout in connection tracking and DHCP leases occur simultaniously you cannot decide which one caused the effect.
Reopening the browser may also help. But this is no admin tool.
Thank you @sec-con I learned something new today thanks to you. After your post I went trough this rabbit hole and I found out that a new firewall rule will not affect the already established and tracked connections. As stated by @bbitsch it seems to me that a conntrack flush should be issued after a new rule is entered in the WUI.
I will be happy to submit to bugzilla but not really sure what to put in there that is a good technically oriented text as to what we discovered with this thread.
Needless to say, I did not think this thread would evolve as it has, kinda expected shorter answers and more shrugs “there goes that silly guy again…”
If you describe the issue “client isn’t blocked despite a blocking fw rule” it would be sufficient.
Usually the discussion in Bugzilla specifies the problem further.
In this special case there is a solution, but it lacks for the concrete implementation.
