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?)
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.
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.
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.