5 year old Scheduler Bug? Not dropping states but is this by design? hmm
-
Hello, my first post on the forum! I have recently just discovered pfSense and have built my new gateway running 2.4.4-RELEASE-p3. I am impressed with what the pfSense can do but i am a bit concerned on potentially using it in my business due to what looks like a bug that appears to have been in the platform for 5 years, but does not seem to be fixed?
My scenario. I have a large amount of files that i am moving to Azure, between 12 - 6am i want the host doing the upload to use the full bandwidth, between 7am- 11pm i want the host to be have a restricted bandwidth.
I have configured the limits, i have configured the firewall rule to use the limits, and i have configured a schedule for 7am-11pm . At 12am you can see the firewall rule become inactive, hence its passed and the host consume all the bandwidth - Great (I can see this happen in the traffic graph etc)!! At 7am though, you can see that the fire wall rule becomes active again, but it does not limit the bandwidth from the host. To me what appears to be happening is that the AzCopy upload has already established its session and for some reasons pfSense does not apply a limit to it. As soon as i clear the state tables for the host the limits get applied and it all works great.
i have spent a lot of time searching on this, and it looks like i am not the only one with this issue (states not being reset on schedules) and it goes back to 5 years ago, is this really right? it really make me question whether i should continue my pfSense journey.....
I have also tried creating a rule for limited bandwidth, and a rule for unrestricted at the times above to see if it was that, but same problem.
anyone have any ideas? or have this actually working :)
any help greatly appreciated!
-
I recall working on something similar and swapping the default and the exception helped with what I was doing. I am sorry but I can't remember any more details.
-
Thanks for the reply, so basically I should swap the rules around and see if that works. Hmm
-
What is the schedule configuration for the Unrestricted schedule?
-
-
When the schedule expires at 23:59, the states created by that schedule are killed. The client will detect that and reconnect. Trouble is there is no active schedule at that time because it is in the window between 23:59 and 0:15 so the traffic will be passed, and the state created, by the pass any rule without a schedule on it.
Only states created by a schedule rule are killed when that schedule period ends.
Why does that schedule not begin at 0:00? Why 0:15?
You could also put a reject rule for source 192.168.0.3 right after the two schedule rules to guarantee that no states would be created for that host by a rule without a schedule on it.
I would do both. I would change the unrestricted rule to begin at 0:00 and place the reject rule right after.
-
@Derelict Thanks again for the reply.
I actually adjusted the times as i wanted to give the system enough time to change the states, hence the 15 min gap. I have now changed them to the 0:00 as suggested.
The question i have though, why do i even need the unlimited rule? Should it not work such as this....
-
Normal operation, no limits, no rule running as its not in the scheduled time = full bandwidth (various states would be created for the sessions)
-
Restricted rule Schedule starts - this applies limits to the existing states (i have seen it do this when i had it the opposite way round, e.g connection was always restricted until this time, then it goes full bandwidth) as you can see in the screen shot.
-
Restricted rule stops - states get deleted, clients reconnect and go back to full bandwidth
thanks
-
-
Because states are killed when the schedule on the rule that created the states expires.
If the rule that creates the unlimited state has no schedule that state will never be automatically killed even during the limited schedule period.
Restricted rule Schedule starts - this applies limits to the existing states
No, it doesn't. Whatever you saw wasn't that. It applies the limits to the states it creates.
I have given you exactly what you need for the behavior you seek.
-
@Derelict said in 5 year old Scheduler Bug? Not dropping states but is this by design? hmm:
Because states are killed when the schedule on the rule that created the states expires.
If the rule that creates the unlimited state has no schedule that state will never be automatically killed even during the limited schedule period.
Restricted rule Schedule starts - this applies limits to the existing states
No, it doesn't. Whatever you saw wasn't that. It applies the limits to the states it creates.
I have given you exactly what you need for the behavior you seek.
Thanks again for the help and response, my question was so that i could better understand how this feature works, which i now do. Its working fine now following your steps :)
