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

    IPSec + WAN Limiters

    Scheduled Pinned Locked Moved Traffic Shaping
    8 Posts 3 Posters 3.9k Views
    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.
    • R
      RobEmery
      last edited by

      Hello

      I'm at a loss to explain the following limiting behaviour on PFSense 2.1.4-RELEASE

      We are attempting to provide bandwidth limiting as follows:
      The combined traffic over the WAN needs to not exceed 10MBit

      We have LAN, WAN and an IPSec Tunnel (which uses the WAN)

      Initially we tried:

      a floating rule on WAN
      with:
        direction out
        protocol any
        Gateway is configured
        In = WAN_UP
        Out = WAN_DOWN

      This seems to limit downloads from a machine on the LAN downloading
      from the internet; however if a machine downloads over the IPSec
      then the bandwidth limit is exceeded.

      It would appear that the traffic sent by the IPSec over the WAN
      is not included/matched by the floating rule

      We have tested shapers on the LAN, the IPSec interface and the WAN and
      it would appear that the only way to limit IPSec's throughput is to both:

      • Limit on the LAN interface, with the destination address of the remote tunnel

      • Limit the IPSec interface for connections that have been initiliased from the remote end

      So we have come to the following conclusion:

      Floating out WAN  Can limit downloads from the internet
      LAN                Can be used (with the appropriate dest addr) to apply download limit over the IPSec
      IPSec              Can be used to a limit downloading from the other end of the tunnel

      Is this correct/the only way of doing it?

      Many Thanks,
      Rob

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

        What you explain sounds correct. IPsec packets are seen out of the IPsec interface, not WAN, and therefore I don't think they can be placed under the same limiter.

        What you can do, is to use the HFSC shaper and upperlimits instead of limiters. The upperlimit on the WAN interface will then include IPsec traffic (and I can tell you for sure because I have configured it this way at work).

        Hope this helps.

        Regards!

        If it ain't broke, you haven't tampered enough with it

        1 Reply Last reply Reply Quote 0
        • R
          RobEmery
          last edited by

          @georgeman:

          What you explain sounds correct. IPsec packets are seen out of the IPsec interface, not WAN, and therefore I don't think they can be placed under the same limiter.

          What you can do, is to use the HFSC shaper and upperlimits instead of limiters. The upperlimit on the WAN interface will then include IPsec traffic (and I can tell you for sure because I have configured it this way at work).

          Hope this helps.

          Regards!

          Ah! I didn't know about the HSFC mechanism there, thanks!

          Does it matter which direction you apply the queue? Do you need 2 rules, in opposite directions with opposite queues configured?

          Thanks,
          Rob

          1 Reply Last reply Reply Quote 0
          • D
            dreamslacker
            last edited by

            @RobEmery:

            Ah! I didn't know about the HSFC mechanism there, thanks!

            Does it matter which direction you apply the queue? Do you need 2 rules, in opposite directions with opposite queues configured?

            Thanks,
            Rob

            Yes, it does matter especially when the rate control is asymmetric for upload/ download.

            I would avoid using HFSC Upperlimit as far as possible.  My experience is that it can cause weird latency issues even for traffic that rides on queues without Upperlimit set.

            I'd recommend using rate limiters instead and shaping within the tunnel as opposed to the tunnel itself (via WAN).

            Implement the limiters using rules in the specific interface tab rather than the floating tab to do it would likely be less confusing.

            e.g.
            You have a WAN_UP limiter to limit your total uploads and WAN_DOWN to limit the total downloads.

            In all your LAN rule(s) except those that are specific to local traffic (to pfSense unit itself), make sure to set the limiter to IN = WAN_UP, OUT = WAN_DOWN.
            Repeat the same for the IPSEC tab rule(s).

            If you have any port forward rules (under WAN tab), you will also need to set the Limiters but in reverse (the direction is now reversed with respect to your Local network).

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

              Regarding the HFSC upperlimits option: if you don't need the shaper functionality, you don't really even need queues or rules. Just create a single queue on the root interface, set it as the default queue and specify the linkshare m2, upperlimit m2 and bandwidth to the same value. That's it

              If it ain't broke, you haven't tampered enough with it

              1 Reply Last reply Reply Quote 0
              • R
                RobEmery
                last edited by

                @dreamslacker:

                I'd recommend using rate limiters instead and shaping within the tunnel as opposed to the tunnel itself (via WAN).

                Implement the limiters using rules in the specific interface tab rather than the floating tab to do it would likely be less confusing.

                e.g.
                You have a WAN_UP limiter to limit your total uploads and WAN_DOWN to limit the total downloads.

                In all your LAN rule(s) except those that are specific to local traffic (to pfSense unit itself), make sure to set the limiter to IN = WAN_UP, OUT = WAN_DOWN.
                Repeat the same for the IPSEC tab rule(s).

                This is pretty much what we have currently; however we (I don't really understand why) have to put a different limiter (VPN_UP, VPN_DOWN) on the IPSec interface, otherwise it looks like it gets double-shaped and we seem to be only able to pull about 4MBit (when all the limits are set to 10MBit).

                Ideally I'd like to just sort of go bang 1 or 2 rules that applies a 10MBit limit to the WAN in both directions; including all IPSec traffic etc hopefully the queues can do this?

                1 Reply Last reply Reply Quote 0
                • R
                  RobEmery
                  last edited by

                  @georgeman:

                  Regarding the HFSC upperlimits option: if you don't need the shaper functionality, you don't really even need queues or rules. Just create a single queue on the root interface, set it as the default queue and specify the linkshare m2, upperlimit m2 and bandwidth to the same value. That's it

                  Cool, I'll hopefully find a windows to try this later on today

                  1 Reply Last reply Reply Quote 0
                  • D
                    dreamslacker
                    last edited by

                    @RobEmery:

                    This is pretty much what we have currently; however we (I don't really understand why) have to put a different limiter (VPN_UP, VPN_DOWN) on the IPSec interface, otherwise it looks like it gets double-shaped and we seem to be only able to pull about 4MBit (when all the limits are set to 10MBit).

                    Ideally I'd like to just sort of go bang 1 or 2 rules that applies a 10MBit limit to the WAN in both directions; including all IPSec traffic etc hopefully the queues can do this?

                    Did you check if you're indeed double shaping though?

                    i.e.  You're shaping both within the tunnel and the tunnel itself (WAN traffic) because your tunnel is caught in the WAN rules and the traffic in the tunnel itself is also caught in another set of rules.

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