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