FW rule schedule block issues
-
I know this is not a new issue but am revisiting it since I'm on new pfS version and perhaps there's new info around.
I have done some tests using a WD media player, playing a shoutcast stream.
I have then set up a FW rule with a schedule that blocks at specific time then becomes inactive again.
When time is met nothing happens and the only way to stop it is either to stop the stream and re-start it (like someone changing shoutcast feed in GUI), then it is not allowed (new session) or resetting states globally.
How should this be handled? For normal web browsing the block schedule is good enough but it does not work when there are continual streams set up etc (is problem also with gaming sessions), so how to handle this?
One suggestion I've seen is to alter the logics and instead of using scheduled block rules use schedules allow rules instead and using always-on block rules in conjunction, instead of the other way around.
Any other ideas here, will there come an option to kill states (perhaps only the effected ones, the ones being targeted by the FW-rule) in future?
TIA,
2.2-RELEASE (i386)
This is also discussed here: https://redmine.pfsense.org/issues/3558
This issue is discussed here too:
https://forum.pfsense.org/index.php?topic=54071.msg289254#msg289254 -
I thought I should do a follow-up just in case someone else is interested.
I tested rebuilding a ruleset on one interface to have the allowed action being explicitly allowed by a scedule and having blocking action done by a static block rule below.
I played the shoutcast stream again and when the allowed rule became inactive pfS did indeed shut it down without me having to touch states etc.
I guess this is a workaround then and indeed rethinking the rules probably would work in most cases. Still, it is handy to be able to use both allowing and blocking scheduling rules for flexibility when building the ruleset so I'd be interested in any future changes in how blocking action together with scedules work in pfS.
-
Yes, at the moment that works only for pass rules in a schedule. When the rule turns on, you get the access because the pass rule is added to pf. From then, pf can keep a list of which states were allowed because of that rule. Then when the schedule ends, pfSense can tell pf to kill any states that were alowed because of that rule, plus remove the rule.
The logic is harder for a scheduled blocking rule. At the END of the schedule it is easy, the rule is removed from the rule set and now users get more access… but when the schedule starts, pfSense somehow needs to identify which states would be effected by the block rule, if it had been there. Because pf is not already tracking that information, it is not so easy to work out. It is algorithmically solvable - but not easy to look through every state and then see if it would be blocked by the (potentially complicated) new block rule, and kill the state.