Time Based Rule for Blocking
-
I have a specific set of IP addresses that I want to block from communicating outside of the network between the hours of 2200 and 0900 daily.
I did a little digging and found that you can't set a range that runs overnight (beyond 2359).
So, obviously, my time range is now 0900 to 2200 daily ALLOW, rather than 2200 to 0900 BLOCK.
So, what's the best way to set-up a firewall rule that blocks all outside communications (LAN to WAN to Internet) between 2200 and 0900 daily, while allowing communications 0900 to 2200 daily. (The exact time isn't important. It could be 0859 to 2159 so the rules will mesh up properly.)
It feels like it's going to be a primary block, with a secondary allow? Or is it primary allow (first rule), with a secondary block (fall through, second rule)?
I've never done one of these before, so I appreciate the help.
-
@amarand said in Time Based Rule for Blocking:
So, obviously, my time range is now 0900 to 2200 daily ALLOW, rather than 2200 to 0900 BLOCK.
You could simply define the block as 0-9 and 22-24 if you want it blocking:
There's no problem with that :)
Cheers
-
I'd not recommend the use of a scheduled block rule. It will not cut already opened connections when it gets active at schedule time and only blocks new connections.
Better to set up a scheduled pass rule, followed by a persistent block rule for the concerned traffic.Also ensure that System > Advanced > Miscellaneous > Do not kill connections when schedule expires is not checked.
-
@viragomann Totally right and I forgot to mention that! Thanks!
He's right. Better do the "allowing" schedule instead of blocking! Reason for that is, that pfSense clears states that are attached to such a schedule rule. If you do the blocking, the block goes up, but the states allowing the traffic were allowed by a different rule (usually below the blocking one) and that is still active. So the stated of said allow rule won't be cleared and e.g. the kids will still have access to the games/websites they are currently on. Only new connections are blocked by the rule.
If you do the same with an allow rule followed by a reject/block rule of the same setup, then that scheduled pass rule allows the traffic to times you specify and after the schedule disables it (because we are after 22h) the states of the allow rules are cleared and the following reject rule is in full effect. After the rule gets active again, it instantly will get hits, as rejects/blocks don't create states so new connections will go through the rules list every time and will see the newly active schedule-rule again.
So in your example:
- create a schedule for 9am to 10pm on every day
- create an allow rule with the specifics you like (source alias, destination etc) and attach it to the schedule
- clone that rule, change it to reject/block and remove the schedule
- put the reject/block exactly below the pass rule with the schedule
- save
- apply
-
@jegr Hi, thanks for all the information contained in this tread. I’ve been trying to get a “block on schedule” rule working for the past month and did not realize that already open connections stay open. Out of curiosity, what is the reason for implementing block rules this way? Or what is the use case?
-
@hammer8 said in Time Based Rule for Blocking:
@jegr Hi, thanks for all the information contained in this tread. I’ve been trying to get a “block on schedule” rule working for the past month and did not realize that already open connections stay open. Out of curiosity, what is the reason for implementing block rules this way? Or what is the use case?
That's not an implementation reason, but a rule-logic or better stateful firewall one. Stateful firewalls use - of course - states so they can work faster. A state is created when a pass rule is evaluated and executed -> the traffic passes and all(!) subsequent traffic for that connection is also supposed to do that. To make that easier, faster and smoother, the packet filter (pf in that case) creates a state. That state is created with the very first syn packet (in case of TCP connections) or the first matched packet of a UDP or ICMP connection. After that state is created, every subsequent packet retrieved is always matched against the current state table first, then - if no state is found - the firewall rules are evaluated. So a big ruleset is only run through if a packet doesn't have an active state yet but if it created one (e.g. it matched a pass rule), all further packets are hits against the state table which can be accessed and matched far faster then parsing through big lines of rules in a firewall table.
The state table of course doesn't create a state for blocks. And that's the point! If you create a schedule with a block statement, that is disabled at first and e.g. goes up at 10pm so kids shall go to sleep and don't play any longer ;) then the kid's computer at 9:59pm still uses the normal "allow rule" to create states for e.g. surfing or playing minecraft online. Your block rules comes online at the scheduled time, BUT: the ruleset isn't asked(!) as there is already a "pass" state in play that came from before that block was active. So as states are evaluated first, the traffic still passes and won't check against the (now new) rule table. Only when that state expires or gets closed, the state is cleared and a new connection is matched against the rule table again.
That's why the other way round is the correct/better on: Your default ruleset is "block the kids computer" (still an example but you get it). And you have an allow rule in place with a schedule, that allows playing online from 10am to 10pm. Then what happens is that pass rule - while active - gets matched, a state created and the kid can play. At 10pm the rule will be deactivated and because the filter knows the rule's ID, all states connected with that particular rule ID will get purged to force a re-evaluation of rules. So the next packet of an active session passes the firewall, but the state is already deleted so the state won't match. The rules will be evaluated and - voila - the packet is blocked instantly. A reset or retry won't help either as the block will stand. So this way because we know the rule ID in question that is on a schedule and gets disabled, we know which states to clear and force the connections down that already exist.
The other way round if you disable/enable a blocking scheduler rule you simply don't know which other rule after that on has allowed traffic that now gets blocked. It could be an allow any rule, it could be an allow this IP to any rule, it could be an alias, etc. the filter simply doesn't and can't know. With an allow rule that gets disabled, we know this rule isn't active anymore and all connections that were associated with it shall now end immediatly. So connections are severed and closed almost on instant.
Cheers :)
\jens -
@jegr Hi, thank you for a most excellent explanation! Really helps to understand how it all works. Much appreciated…have a great day!
-
@hammer8 My pleasure
