Project

General

Profile

Actions

Bug #3558

closed

Schedule States in System - Advanced - Misc not working

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

Status:
Resolved
Priority:
Normal
Category:
Rules / NAT
Target version:
Start date:
03/30/2014
Due date:
% Done:

100%

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


Files

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 https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting).

Actions #2

Updated by Chris Buechler over 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 over 10 years ago

  • Assignee set to Jim Pingle

Assigned to Pingle for evaluation and resolution.

Actions #4

Updated by Jim Pingle over 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 over 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 https://github.com/pfsense/pfsense/pull/1239

Actions #6

Updated by Phillip Davis over 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 over 10 years ago

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

Actions #8

Updated by Phillip Davis over 10 years ago

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

Updated by Richard Coyote over 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. https://forum.pfsense.org/index.php?topic=54071.msg383969#msg383969)

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 https://forum.pfsense.org/index.php?topic=78755.msg429660#msg429660 but I think pere's posting above is more instructional.

Actions #11

Updated by Phillip Davis over 10 years ago

Philippe 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 over 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 https://redmine.pfsense.org/issues/3558#note-10 worked fine in my testing, but failed completely when I tried to use it in production.

Actions #13

Updated by Chris Buechler almost 10 years ago

  • Assignee changed from Ermal Luçi to Chris Buechler

mine for testing

Actions #14

Updated by Chris Buechler almost 10 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.

Actions

Also available in: Atom PDF