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

    Unable to limit bandwidth on schedule

    Traffic Shaping
    2
    8
    913
    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.
    • B
      blueh2o
      last edited by

      I am trying to limit bandwidth during the day between two VPN endpoints but it's not working. The link has a maximum speed of 30Mbps. Backup jobs are being sent over this link, but I want to limit the backup jobs to 15Mbps during the day so that other traffic can flow. I have created a schedule, a limiter, and a floating match rule. The schedule goes to active or inactive at the appropriate times, but the limiter doesn't have any effect unless I reset the state tables. How do I get the rule to follow the schedule like it should?

      S 1 Reply Last reply Reply Quote 0
      • S
        SteveITS Galactic Empire @blueh2o
        last edited by

        @blueh2o It's been a while since I messed with this, long enough I don't recall the issues. Can you post your limiter details? Are all times covered by a schedule?

        In the end for our usage I found rsync has a bandwidth parameter and so ended up using that. Then on the both ends used a match rule to put the traffic in a low priority queue, with no limiter in pfSense. I know this doesn't answer your question but may be helpful.

        param: --bwlimit=7000
        This option allows you to specify the maximum transfer rate for the data sent over the socket, specified in units per second. The RATE value can be suffixed with a string to indicate a size multiplier, and may be a fractional value (e.g. "--bwlimit=1.5m"). If no suffix is specified, the value will be assumed to be in units of 1024 bytes (as if "K" or "KiB" had been appended). See the --max-size option for a description of all the available suffixes. A value of zero specifies no limit.

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote 👍 helpful posts!

        1 Reply Last reply Reply Quote 0
        • B
          blueh2o
          last edited by

          6b85a9b7-01c5-46a7-86d3-6f3dab6a3450-image.png
          22875799-caa1-4c9e-8da0-a6c6e8e21554-image.png
          b11e661b-ce4a-49ae-9fb3-73f0c09db983-image.png
          06bb96cd-bd10-41f6-ba30-0d76a0070242-image.png

          S 1 Reply Last reply Reply Quote 0
          • S
            SteveITS Galactic Empire @blueh2o
            last edited by

            @blueh2o It looks like you have one schedule and the limiter has no schedule assigned. Per the docs , "If a limiter contains multiple bandwidth specifications, they must each use a different schedule. For example if the firewall has a “Work Day” schedule, then it must also have an “Off Hours” schedule that contains all of the time not included in “Work Day” for the second bandwidth specification."

            It looks like you need to 1) create more schedules for 7p-11:59p and 12a-7a, then 2) click +Add Schedule on the limiter to add the two new limits and schedule.

            https://docs.netgate.com/pfsense/en/latest/firewall/time-based-rules.html#defining-times-for-a-schedule
            "The time cannot cross midnight on any day"

            Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
            When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
            Upvote 👍 helpful posts!

            B 1 Reply Last reply Reply Quote 0
            • B
              blueh2o @SteveITS
              last edited by

              @steveits Am I doing this correctly?
              64302871-2f1e-473f-9198-7210c2c7a7f2-image.png
              393dc5d8-6eda-4198-9486-a62aeaec3ac1-image.png
              19940c03-92a4-45a7-9138-f615a014af45-image.png
              2ac833ce-cb57-4fb9-92d6-130bfc94add3-image.png

              S 1 Reply Last reply Reply Quote 0
              • S
                SteveITS Galactic Empire @blueh2o
                last edited by

                @blueh2o I think so. re: in/out pipes:

                "In general, a limiter should mask the Source Address on Upload (In) limiters for LAN-type interfaces, and Destination Address on Download (Out) limiters on LAN-type interfaces. Similar to swapping the directionality of the limiters when applying to LAN and WAN, masking is swapped as well, so the same masked limiter set for In on LAN should be used for Out on WAN."

                You mentioned a floating rule though? which I think are a bit different. Overall if it isn't being applied as you expect, check that the state is in the direction you think it is. For instance a limiter downloading from a web server needs to apply to the request going to the web server because the return is just a reply not a new connection, and "uses" the open state.

                Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                Upvote 👍 helpful posts!

                B 2 Replies Last reply Reply Quote 0
                • B
                  blueh2o @SteveITS
                  last edited by blueh2o

                  @steveits I checked previously with logging turned on to ensure the correct traffic is matched. For now I'll wait and see what happens at 18:59.

                  1 Reply Last reply Reply Quote 0
                  • B
                    blueh2o @SteveITS
                    last edited by blueh2o

                    @steveits it worked. Thanks for the help.
                    Screenshot_20220211-190050.png

                    1 Reply Last reply Reply Quote 1
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.