IPSec + WAN Limiters



  • 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



  • 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!



  • @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



  • @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).



  • 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



  • @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?



  • @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



  • @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.