Bug #3558


Schedule States in System - Advanced - Misc not working

Added by Doktor Notor over 10 years ago. Updated over 9 years ago.

Rules / NAT
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


schedule_states_workaround.png (17.1 KB) schedule_states_workaround.png Richard Coyote, 06/30/2014 04:44 PM
Actions #1

Updated by Dig dug3 over 10 years ago

Best thing would be to add a checkbox to the firewall rules "reset state(s) when activated".
This would also resolve rules not working when a new rule has been created and activated (Dangling states

Actions #2

Updated by Chris Buechler about 10 years ago

  • Category set to Rules / NAT
  • Target version set to 2.2

this definitely works to some degree but apparently some cases where that's not true.

Actions #3

Updated by Jim Thompson about 10 years ago

  • Assignee set to Jim Pingle

Assigned to Pingle for evaluation and resolution.

Actions #4

Updated by Jim Pingle about 10 years ago

  • Assignee changed from Jim Pingle to Ermal Luçi

This is definitely a problem. It appears to be due to the timing and boundaries of the schedules.

If you end a schedule at xx:15 the filter reload runs and since the time is still xx:15 it considers it in-schedule. If you wait a minute and trigger a manual reload of the filter it does cut off the connection as expected.

So somehow the logic in filter_get_time_based_rule_status() needs to be altered to account for the time difference when checking the range, but only for the end not the start. For the start, the minute should test true if it's included, but for the end the minute should test false if it's an exact match.

This is likely the same reason that the schedules were changed originally so that the end time was 59 and not 00. Perhaps the times on the end could change to 14, 29, and 44 to match? Or one could be subtracted from the minute of the end time.

Actions #5

Updated by Phillip Davis about 10 years ago

I looked at this a while ago and then had trouble replicating the problem. I suspect it only occurs when the filter_configure_sync cron job fires up immediately on the 15-minute interval and the scheduled rule processing and time decision is made in that first second of the 15-minute interval.
Changing the end time comparison should fix that, and might fix the whole thing?
Pull request

Actions #6

Updated by Phillip Davis about 10 years ago

and I think the "59" minute end time option is so that a schedule can go to 23:59 - there is no way to specify 24:00 as an end time to mean midnight at the end of the day, and 00:00 means the very start of the day. I guess code could be added to teach the system that 00:00 end time should be interpreted as the very end moment of the day.

Actions #7

Updated by Chris Buechler about 10 years ago

yeah the 59 was originally added so you can do 23:59.

Actions #8

Updated by Phillip Davis about 10 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #10

Updated by Richard Coyote about 10 years ago

Here is a workaround that works on 2.1.4-RELEASE (i386) for the benefit of those who find this bug report. (I accidentally replicated pere's solution.

Also note that the instructions and examples in the book (pfSense-book-21draft.pdf) section "Time Based Rules" do not clear states regardless of how "Schedule States" in System: Advanced: Miscellaneous: Schedules is set. However, if you invert the logic of the example rule the states will get cleared.

I was able to successfully get pfSense to clear states at rule activation by creating a pair of rules:
PASS Source (Scheduled for periods when rule is to PASS traffic)
BLOCK Source (no schedule)

Here's my workaround but I think pere's posting above is more instructional.

Actions #11

Updated by Phillip Davis about 10 years ago

@Richard: I fixed up the timing of the schedule end, so now the state clearing code should be executed at the correct time. Can you confirm if this little fix has fixed the overall problem? Or is there also an issue with the relevant states actually getting matched and cleared correctly?

Actions #12

Updated by Richard Coyote about 10 years ago

@Phillip: I confirmed that your fix was in my test unit. The states still do not get cleared.

There are some subtleties as well. All my tests with scheduled Block rules fail. (The example rule in the book fails.) However, some of my tests are successful when I invert the logic (i.e. place an Allow rule ahead of the block rule and schedule the Allow rule). I haven't had time to look at the code yet (actually still trying to get access through the new ssh key system) but based on my testing, it feels like the pattern matching might be broken. Single IP addresses seem to get cleared better than aliases or subnets. I should mention that my "workaround" above worked fine in my testing, but failed completely when I tried to use it in production.

Actions #13

Updated by Chris Buechler over 9 years ago

  • Assignee changed from Ermal Luçi to Chris Buechler

mine for testing

Actions #14

Updated by Chris Buechler over 9 years ago

  • Status changed from Feedback to Resolved

the original issue here is fixed, and this looks to work fine in general.

Richard: if you can re-test with 2.2 and report back on the 2.2 board of the forum, there might be something else going on in the circumstance you're trying. We can help narrow that down and start a new bug on that if there are any outstanding issues.


Also available in: Atom PDF