Project

General

Profile

Bug #3558

Schedule States in System - Advanced - Misc not working

Added by Doktor Notor over 5 years ago. Updated over 4 years ago.

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

100%

Estimated time:
Affected Version:
All
Affected Architecture:

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

Associated revisions

Revision a43c5bde (diff)
Added by Phillip Davis about 5 years ago

Only include a scheduled rule if it is strictly before the end time

The exact moment of the end time is the end of the schedule. We do not want to include a rule when filter_configure_sync wakes up at 00:15:00 etc and is on a not-slow system that processes this code during the interval 00:15:00 to 00:15:01. This should help intermittent issues with schedules not finishing at the appropriate 15-minute boundary. Might help or fix #3558

Revision efac3a13 (diff)
Added by Phillip Davis about 5 years ago

Only include a scheduled rule if it is strictly before the end time

The exact moment of the end time is the end of the schedule. We do not want to include a rule when filter_configure_sync wakes up at 00:15:00 etc and is on a not-slow system that processes this code during the interval 00:15:00 to 00:15:01. This should help intermittent issues with schedules not finishing at the appropriate 15-minute boundary. Might help or fix #3558

History

#1 Updated by Dig dug3 over 5 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).

#2 Updated by Chris Buechler about 5 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.

#3 Updated by Jim Thompson about 5 years ago

  • Assignee set to Jim Pingle

Assigned to Pingle for evaluation and resolution.

#4 Updated by Jim Pingle about 5 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.

#5 Updated by Phillip Davis about 5 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

#6 Updated by Phillip Davis about 5 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.

#7 Updated by Chris Buechler about 5 years ago

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

#8 Updated by Phillip Davis about 5 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#10 Updated by Richard Coyote about 5 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.

#11 Updated by Phillip Davis about 5 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?

#12 Updated by Richard Coyote about 5 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.

#13 Updated by Chris Buechler over 4 years ago

  • Assignee changed from Ermal Luçi to Chris Buechler
  • Affected Documentation 0 added

mine for testing

#14 Updated by Chris Buechler over 4 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