Traffic Shaper not behaving – qHigh not working



  • Hi All,

    I have a certain IP that i want to have the HIGHest priority and another IP i want to have the lowest priority when it comes to traffic.  I followed a couple guides and i got the low priority IP to start going through that queue, but the high priority queue is not working!  Here are some screenshots to show you what i've done:

    ![Floating Rules.PNG](/public/imported_attachments/1/Floating Rules.PNG)
    ![Floating Rules.PNG_thumb](/public/imported_attachments/1/Floating Rules.PNG_thumb)





  • Are you making the mistake of using Pass instead of Match for your floating rule's Action?



  • Do you have your interfaces rate limited?



  • @KOM:

    Are you making the mistake of using Pass instead of Match for your floating rule's Action?

    I did have it set to Pass, but that was working for the qLow  IP.  I changed to Match and got no change that i can tell on the qHigh queue.

    My Interfaces are not limited at all.


  • LAYER 8 Netgate

    You don't have qHigh defined on LAN.

    Your floating match rules will not match on WAN out because NAT has already happened and the source address is no longer the host address but the mapped address.

    Add qHigh to your LAN interface and it should start behaving as expected as long as LAN in is included in the list of interfaces on the floating rules.



  • @Derelict:

    You don't have qHigh defined on LAN.

    Your floating match rules will not match on WAN out because NAT has already happened and the source address is no longer the host address but the mapped address.

    Add qHigh to your LAN interface and it should start behaving as expected as long as LAN in is included in the list of interfaces on the floating rules.

    qLow isn't defined in LAN either, but its behaving properly.  Why is that the case?

    Doesn't seem that made a difference.  I've confirmed that LAN was included in the list of interfaces on the floating rule as well.


  • LAYER 8 Netgate

    Are you sure?

    What are all the specifics of the floating rules?

    The table doesn't show enough.

    You have to be positive you're creating new states after making changes.



  • I'll attempt to reset my states one more time and report back.



  • It did not make a difference after resetting the states.  Here is a list of the TCP floating rules.  The UDP are the same just with qACK unselected.

    ![Screen Shot 2015-12-01 at 12.25.44 PM.png](/public/imported_attachments/1/Screen Shot 2015-12-01 at 12.25.44 PM.png)
    ![Screen Shot 2015-12-01 at 12.25.44 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-12-01 at 12.25.44 PM.png_thumb)
    ![Screen Shot 2015-12-01 at 12.25.58 PM.png](/public/imported_attachments/1/Screen Shot 2015-12-01 at 12.25.58 PM.png)
    ![Screen Shot 2015-12-01 at 12.25.58 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-12-01 at 12.25.58 PM.png_thumb)
    ![Screen Shot 2015-12-01 at 12.26.09 PM.png](/public/imported_attachments/1/Screen Shot 2015-12-01 at 12.26.09 PM.png)
    ![Screen Shot 2015-12-01 at 12.26.09 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-12-01 at 12.26.09 PM.png_thumb)
    ![Screen Shot 2015-12-01 at 12.26.21 PM.png](/public/imported_attachments/1/Screen Shot 2015-12-01 at 12.26.21 PM.png)
    ![Screen Shot 2015-12-01 at 12.26.21 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-12-01 at 12.26.21 PM.png_thumb)


  • LAYER 8 Netgate

    Quick does nothing on match rules. I don't think it'll break them but I'd uncheck it because it's wrong.

    Certainly looks like it should be properly queueing the traffic to me.



  • It looks like some traffic is passing through the qHigh queue now.  But not much…only a few bps.



  • Quick does nothing on match rules.

    Setting Quick changes the floating rule behaviour from last-match to first-match.  Quick is the default for all non-floating rules, but it is optional here.


  • LAYER 8 Netgate

    I don't think that's true on Match rules. I think match rules are always last match wins.

    Give the floating rule set posted it shouldn't matter either way in this case.


  • LAYER 8 Netgate

    I just looked and pfSense happily sets quick on match rules and the pf man pages don't say anything about it that I can see.

    I'm probably thinking about the last line (outdated) here:

    https://doc.pfsense.org/index.php/What_are_Floating_Rules


  • Banned

    Match rules do not work with quick selected.



  • Still does not seem to be working.  Any other ideas with what could be wrong on my config?



  • Match rules do not work with quick selected.

    Is that by design?  The pfSense book seems to imply that it should:

    12.6.5 Quick
    The quick controls whether rule processing stops when a rule is match. The quick option is added to all Interface rules
    automatically, but on Floating rules it is optional. Without quick checked, the rule will only take effect if no other
    rules match the traffic. It reverses the behavior of “first match wins” to be “last match wins”.
    In most situations, it is advised that you always leave quick selected. There are certain specific scenarios where leaving
    quick unchecked is necessary, but they are few and far between. For most, the only rules they would have without
    quick selected are traffic shaper rules.


  • Banned

    @KOM:

    Is that by design?  The pfSense book seems to imply that it should:

    Try 12.6.4



  • Gah.  They are confusing things by using Match in two contexts, as Action and as criteria-based candidate.



  • Do you guys have any idea why my setup would not be working still? I am seeing no traffic pass through my qHigh queue.


  • LAYER 8 Netgate

    Because your rules don't match the traffic you're trying to queue. Doublecheck everything.

    Not that you'd want to leave it that way but you might try a pass rule on LAN from the source addresses that sets the queues.

    You might also want to try explicitly setting the interface on the floating rules to LAN in.



  • You could just say the hell with it all and just use CoDeL. In a home environment with Voip (Ooma and cell phone based voip) heavy downloads and a 1 person playing an online game (CS:GO), no one saw any problems at all and the call quality was better than with my last setup using HFSC.


Log in to reply