Bug #3558
closed
Schedule States in System - Advanced - Misc not working
100%
Description
Simply does not work, the states of existing connections are NOT cleared on expiration time
https://forum.pfsense.org/index.php?topic=68000.0
https://forum.pfsense.org/index.php?topic=74101.msg406248#msg406248
https://forum.pfsense.org/index.php?topic=54071.msg386245#msg386245
and others.
Files
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).
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.
Updated by Jim Thompson over 10 years ago
- Assignee set to Jim Pingle
Assigned to Pingle for evaluation and resolution.
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.
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
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.
Updated by Chris Buechler over 10 years ago
yeah the 59 was originally added so you can do 23:59.
Updated by Phillip Davis over 10 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset a43c5bdea7ee07a5075d8c22a7a247424669e6f3.
Updated by Phillip Davis over 10 years ago
Applied in changeset efac3a1346867481d6cfcea62c131ad0c0de391b.
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.
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?
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.
Updated by Chris Buechler about 10 years ago
- Assignee changed from Ermal Luçi to Chris Buechler
mine for testing
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.