Outbound shaping only, how?



  • I can't seem to get any traffic to go to rules other than qAck, qDefault and qOthersLow on version 2.1RC1. The only reason it goes to the latter two is qDefault is checked default, and qOthersLow is a catch-all rule at the end of the floating rules.  I can't get qVoIP or qOthersHigh to shape traffic.  I want to CBQ shape only outbound so I'm looking for a summary list of must have's. Do or do I not need the following.  If no, please explain.

    • By WAN interface with child queue's only, no by LAN interface needed, YES/NO?

    • Do I need a matching WAN rule to the Floating rule, for traffic to shape, or is this old version workaround, YES/NO?

    • Should floating rules use the MATCH or PASS action?

    • If traffic such as Unbound serving the LAN is being generated by PfSense, not passing into the LAN or WAN, how is this shaped, using a WAN rule and FLOATING rule?  I tried source IP "PfSense" alias and destination port DNS to shape Unbound outbound traffic to public recursive DNS servers, no go.

    • Why does the wizard create a separate floating rule for TCP and UDP rather than using TCP/UDP?  Do they require different Ack/Queue, YES/NO?  I've seen some use Ack/Queue for just TCP and others for both.  I've also read that the Ack is just for outbound and Queue is just for inbound, not sure I buy it, YES/NO?

    I think this covers all the missing or misleading posts in my effort to get all queue's shaping properly.
    Thanks for your help…



  • Try my approach to shaping (as explained here: http://forum.pfsense.org/index.php/topic,65122.0.html ). For me, this approach makes shaping easier to manage.



  • Senser,
    So before your "match tag" rules you place all of your "apply tag" rules?  I'm not sure it's much of an advantage assigning in the Queue field or in the Advanced, Tag field.  Tagging simply requires additional rules for matching in addition to what is typically needed.  Does it offer any other advantage in monitoring logs or what?  In my situation, described below, I don't think it would have mattered the method.

    I worked on this a bit more, over the weekend, and found the queue assigned to default has to be considered.  I had/have, as required, one queue assigned as default named qdefault.  I also have a habit of putting a catch-all rule at the end of my floaters to prioritize, as default, any packets not matching the rules above.  PfSense apparently gets confused by doing this.  As soon as I removed my catch-all floating rule and relied on qdefault being the default queue everything began to work normally.  Well other than the fact the numbers don't quite add up, explained here; http://forum.pfsense.org/index.php/topic,66347.0.html



  • If you create the "match tag" queues on the WAN interface as floating rules (as explained in my other post) they will be evaluated after all the other interface rules. You do not have to worry about ordering there (you can confirm that using pftop). However, if you use other floating rules on that interface (for example for tagging), you should put the "match tag" rules after those.

    Tagging does not add additional rules (other than those queueing rules). Because you need to queue the packets using rules anyway. My approach liberates you from thinking about directions and interfaces. YMMV of course.



  • BTW: I've had your problems with wrapping my head around certain phenomena. Like, I also had cases where everything looked alright but still: no packets would show up in certain queues. My approach solved all those issues for me.

    Anyway, no matter how you do it, just remember: each queue works on exactly one interface in exactly one direction (outbound).

    "My" approach just implements this behaviour by putting the queueing rules directly "on top of" the corresponding interface. One rule for each queue.


Log in to reply