Floating rule for QoS and qACK?
-
As I've posted before (to deafening silence), although the shaper wizard causes qACK to be created, it seems no traffic ever goes to said queue. Looking at the rules, it's clear this is because nothing causes that to happen. So, looking at the Advanced section for firewall rules, I see you can specify a queue or ackqueue/queue, default being nothing special. So, I assume that if I set qACK/qDEFAULT on the LAN allow any rule I have, ACKs coming back from the internet will go to qACK, but that isn't really what I am interested in. The question I have is: how do you get outbound ACKs to go to qACK? It can't be by editing an existing rule, since the inbound packets I want to queue ACKs for are being allowed due to be replies to existing traffic flows :( Sorry if this is known to everyone, but this all seems to have changed from 1.2.3 when it seemed to just work (as far as memory serves me.) I have googled and looked on the pfsense doc site, but nothing seems to explain this. The only idea I can think of is a floating rule that would say qACK/qDEFAULT or somesuch. Any thoughts would be appreciated…
-
Totally confused now. While waiting for a reply vis-a-vis the floating rule, I did add qACK to the outbound LAN rule and started a big download, and with 9mb/sec inbound, I am seeing 200kb/sec outbound on qACK for the WAN. WTH?
-
I'm sorry I don't really have an answer for you but I was just about to post my own question about the qACK. I'm seeing a lot of drops on mine and I"m not sure why. That would suggest that traffic is trying to get into that queue and I just followed the singleWAN-multiLAN wizard.
-
Well, if you search this particular forum, you'll see more than one post where I've been asking if there is/are bug(s) with the shaper wizard, and have been met with deafening silence, so good luck :(
-
So there is a qAck for the LAN and the WAN (at least thats what the wizard provided for me). I agree with you that I never see traffic in the LAN qAck queue. I dont have any rules setup that would put anything on that queue.
However, I do have traffic in my WAN qAck queue. I send my VoIP traffic to qAck and I send DNS traffic to qAck as an example. If you look at the floating rule(s) made by the wizard, and scroll down to the bottom, expand the queue section. The first pull down menu will allow you to select the WAN qAck queue. The second drop down box will allow you to select the LAN queue you want to use.
-
Ah, okay. Well, none of this (AFAIK) is documented anywhere, and the default setup the wizard generates is broken, since it doesn't set that stuff up.
-
Agreed.
-
Ah, okay. Well, none of this (AFAIK) is documented anywhere, and the default setup the wizard generates is broken, since it doesn't set that stuff up.
Which "stuff" does it not set up? Are you saying you needed to edit the rules for DNS and VoIP to get them using the qACK? I'm just trying to learn what I might need to do to get mine working better.
-
No, what I'm saying is that a vanilla wizard run create qACK, but never creates any rules that use it - as far as I can tell, anyway…
-
My wizard run with single-WAN/Multi-LAN created a rule or two that use qACK. At least it looks that way to me…. Am I missing something?
-
Are you saying that dns rule was created automatically, including setting the queue/ackqueue fields?
-
Yes. I did not create the rule. In the wizard, I did choose for DNS to have a "higher priority".
-
Okay, so you did have to do something though. My complaint was this: prioritizing ACKs is a fairly typical thing for shapers to do, although not required, but if you are not setting anything at all, why does it bother creating the ACK queue at all?
-
The wizard does assign traffic to the ACK queue. The only thing that changed from 1.2.3 to 2.x is that now you manually assign it instead of it being automagically grabbing every single ACK.
I actually prefer 2.0's method, as I don't like p2p ACKs to end up in the ACK queue, cause I don't care about p2p and definitely don't want it to flood the queue and prevent more important traffic. -
Maybe we are having a disconnect here. My point was that it does not assign said traffic by default. There is no comment or documentation or anything else that says this, so some poor stupe who does a vanilla walk-thru of the wizard will get an ACK queue that never has traffic go to it. There is also nothing I've been able to find that tells you how to make 'the right thing' happen. So, it looks broken to the average guy who is used to it working out of the box in 1.2.3. I guess we have a philosophical disagreement here - if you don't like the default behavior because you do P2P stuff, that's your call, and you can tweak the queues as you wish (IMO of course…)
-
So tell me, how DO you 'manually assign traffic to the ACK queue'? Keep in mind the ACKs most people care about are outbound ACKs which are in response to inbound TCP packets. Most of the time those will be inbound TCP flows which are not handled by the normal inbound port forwarding and etc, but rather, response packets to outbound http get commands or whatever. So, there is no inbound rule I can toggle the qACK on for, so… How does this work? Again, I've looked at the doc.pfsense.org site and the traffic shaping guide for 2.0 is completely devoid of any useful information in this regard, which is what my complaint was in the first place. I'm not a dummy, and it isn't obvious to me how this works...
-
It actually should have put in rules that had things such as "qACK / qHighPri" when you say, make HTTPS or something like that a higher priority.
Least it did when I used the wizards last.
-
might be more an "ermal" question cause I'm still not 100% sure about how the shaper works yet, and yes, the wiki and other docs I've seen are either abysmally devoid of anything, or they're so over my head that I can't quite get what they're writing about. Then again ermal is awesome, but tends to be over people's heads :P
I'm not sure why you'd need a rule to shape inbound traffic, unless you're shaping traffic goign to a webserver LAN-side. In which case, I'd think that the default HTTP/S rule would work, as I believe seeing it say soemthing like:
Direction: Any
Source: Any
Destination: Any
Port: HTTP(s)so that would work for both in and outbound traffic.
-
You're missing my point. By definition you don't need a rule for return traffic, and it's the ACKs for that return traffic I care about. I guess it's fortunate this isn't a show stopper for me. If I could get some kind of bridging VM appliance that sat between pfsense and the LAN, that was actually supported, I'd do so in a flash, but I don't, so I guess I deal with the lack of documentation or support.
-
Ahhhh
I think I found out the issue that you're describing. If you do not assign HTTP (or whatever) to a higher or lower priority queue, it is left to the default, which doesn't automagically assign ACKs, due to no rule being there.If you want that behavior though, the easiest way I've found is to create a rule on the floating tab, with something along these lines:
Action:queue
protocol: any
source: any
destination: any
queue: qACK/qDefaultThen, move this rule to the very top of the floating tab before all other rules. All traffic will then have access to the ACK queue by default, and it will allow other assignments to change the traffic to another queue is needed.
The bad news is that there will be an extra rule to process for each state. Under light use, this won't be a problem, but when you get to heavy business rates, it could choke the CPU.