Blocking rules with schedules again, to clarify

[0tt0]

I'd like to double check something about how blocking rules work.

I have schedules/aliases and FW rules set up that does kind of work. It does however seem that they work best when they are active before host is, sort of, or before there's states active.

I found this message http://forum.pfsense.org/index.php/topic,5838.msg34384.html#msg34384  and think I got something of a similar situation here. Especially this phrase: "It seems like the rule set is not automatically reloaded when we pass a scheduled time range." seems relevant. One PC should've been blocked at a specific time yesterday but wasn't. The PC was active before schedule set in.

Now today I enabled another similar rule for that PC (also using aliases and schedules) and it worked directly, but in this case the PC was not connected before the rules was enabled and the schedule was "always on".

I'm not sure if this behavior is consistent, I just tested with a block-all rule pertaining to another PC on LAN and that rule worked without resetting states too it seems, so I'm just a little bit confused.

Can someone verify to me how the behavior should be? If I have a blocking rule using schedules, should it cut live connections when it becomes active or not?

I use 1.2.3 RELEASE

TIA

[GruensFroeschli]

Yes it should block live connections.
This was part of the bounty when this feature was introduced.

Did you make sure that your rules are in the correct order?
Logic with schedules is a bit different than with normal rules.
@http://doc.pfsense.com/index.php/Firewall_Rule_Schedules:

Keep in mind that when the rule is inactive, the rules is not skipped – the opposite action is applied. If you schedule a block, a pass is assumed at all other times. If you schedule a pass, a block is assumed.

[0tt0]

I would say that the order should be correct.

I have it above the "default" allow-all-outbound rule on that interface. And sometimes the rule indeed has worked.

But a follow up on that: when a block rule is out of schedule it is PASSed (the reverse action is assumed), does this mean that rule processing stops after this "PASS" rule or does it continue? In the case of "ordinary" FW rules the first match is used, does the same hold true for a non-active block rule (=which is interpretated as a pass rule) or do they continue processing?

If the source for several consecutive FW rules utilizing schedules match include a specific IP (one could be using a subnet and another the IP specifically) one may have to edit those rules so that not more than one match at any given time I guess. Don't think it makes any difference in this case and there's very few rules on that interface, but it would be good to know.

TIA

[GruensFroeschli]

When a rule catches the rest is no longer considered.
So yes, depending on how your scheduled rule look, the rest of your rules may not be active.

[0tt0]

My bad, I thought of them as a different kind of rule in the set, in that aspect, but I'll have that in mind, not the problem here though.

I again have seen one occurrence of this problem, I had one xbox on one of the internal networks that wasn't allowed to pass through after 2200 but it took a few minutes passed 2300 before it was effectively blocked. There's no other rules blocking that IP so the rule blocking past 23 is that one that should've blocked at 22, schedule details in pic below.

This is the same system that I have reported intermittent problems related to imspector and captive portal for earlier. Could my system be messed up somehow and if so how can I tell (I don't want to make a re-install unless I feel it's needed).

How can one be sure all configs are in proper syntax etc, is there some kind of debugging/syntax checker/self test command that one could use?

TIA