Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    5 year old Scheduler Bug? Not dropping states but is this by design? hmm

    Firewalling
    3
    9
    177
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gcpeters last edited by

      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 :)

      alt text

      alt text

      alt text

      any help greatly appreciated!

      M 1 Reply Last reply Reply Quote 0
      • M
        mervincm @gcpeters last edited by mervincm

        @gcpeters

        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.

        1 Reply Last reply Reply Quote 0
        • G
          gcpeters last edited by

          Thanks for the reply, so basically I should swap the rules around and see if that works. Hmm

          1 Reply Last reply Reply Quote 0
          • Derelict
            Derelict LAYER 8 Netgate last edited by

            What is the schedule configuration for the Unrestricted schedule?

            G 1 Reply Last reply Reply Quote 0
            • G
              gcpeters @Derelict last edited by

              @Derelict

              Hello, here you go - thanks for replying!

              alt text

              1 Reply Last reply Reply Quote 0
              • Derelict
                Derelict LAYER 8 Netgate last edited by

                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.

                G 1 Reply Last reply Reply Quote 0
                • G
                  gcpeters @Derelict last edited by

                  @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

                  1 Reply Last reply Reply Quote 0
                  • Derelict
                    Derelict LAYER 8 Netgate last edited by

                    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.

                    G 1 Reply Last reply Reply Quote 0
                    • G
                      gcpeters @Derelict last edited by

                      @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 :)

                      1 Reply Last reply Reply Quote 1
                      • First post
                        Last post

                      Products

                      • Platform Overview
                      • TNSR
                      • pfSense
                      • Appliances

                      Services

                      • Training
                      • Professional Services

                      Support

                      • Subscription Plans
                      • Contact Support
                      • Product Lifecycle
                      • Documentation

                      News

                      • Media Coverage
                      • Press
                      • Events

                      Resources

                      • Blog
                      • FAQ
                      • Find a Partner
                      • Resource Library
                      • Security Information

                      Company

                      • About Us
                      • Careers
                      • Partners
                      • Contact Us
                      • Legal
                      Our Mission

                      We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                      Subscribe to our Newsletter

                      Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                      © 2021 Rubicon Communications, LLC | Privacy Policy