Limiters + NAT -> broken. Search the fine bugtracker.

With all of the extremes this person is trying to do, it may be better to ask if there is any traffic they want getting through the firewall. I might assume that they only care about HTTP/HTTPS, but even HTTPS may be an issue for them because of filtering. Maybe they should start off with blocking all ports except 80/443.

https://forum.pfsense.org/index.php?topic=63531.0

thanks, i try this.

A major discrepancy of Fair Queueing is per-byte fairness vs per-packet fairness. According to DragonflyBSD's FAIRQ source-code, FAIRQ is per-byte fair… I think. Per-packet can be deceptively unfair, depending on expectations.

Limiting and shaping are two different things.  With a limiter, it is a hard cap regardless of maximum bandwidth.  With a shaper, low-priority queues will get to use all bandwidth until something more important comes along.  This is a simplified explanation of how it really works.

Thanks Deric. Your "1:79, 81:65535" suggestion is what I was looking for.

It's basically the same problem as in here… https://forum.pfsense.org/index.php?topic=91299.0 Sam

My next venture is to learn more about debugging ALTQ so I can see more stats. I am assuming I will need to resort to a full FreeBSD to get more control of the system though. Learning more about FreeBSD is probably a good idea. I bet that the bufferbloat/Codel mailing-list has some great info about how to simulate traffic for testing. I have only played with netperf casually. The few worthwhile tests I ran I did with either multiple sessions of iperf, or multiple sessions of netcat/nc. Netcat is insanely powerful. Every few months since I learned of netcat I am amazed by how powerful the simple tool can be; "netcat host2 port < /dev/zero" to a listening netcat and bam, single stream TCP/UDP traffic. or send a file with the same method. or create a remote shell. That is just the standard uses. There is gns3, but it is Cisco emulation primarily. Good userbase and polished interface. There must be a good, simple simulator, right? Call DARPA maybe? ;)

The wizard attempts to make sure that VoIP traffic goes into qVOIP by directing your SIP server traffic to it, but it doesn't do it by DPI or any magic – just it's address.  If you already have your phones segmented off by themselves then it will be stupid simple.  Create an alias for your phone subnet, then modify the floating rule that directs the VoIP traffic and change the source to be your alias.  Done.  All traffic coming from your phone subnet will be shunted to qVOIP.

Keep sniffing while the queue is active and see which ports are triggering the rule.

1.  Traffic shaping forum is specifically for issues involving the traffic shaper. 2.  You likely had an environmental issue with your line after the storm.  I've seen cases of excess water shorting out a connection that fixed itself with the help of evaporation.

You could also try to make a tunnel specifically for the IPTV traffic –- Then you could shape traffic based upon which tunnel the traffic was received from.

@KOM: I wonder how that TBR interacts with the PRIQ caveat that high priority queues will starve low priority queues of bandwidth if there is enough high traffic?  I believed PRIQ was absolute: higher priority goes first no matter what. That is my understanding as well. The only thing that has changed for me is what controls the bitrate. I had always wondered how PRIQ could have no rate-limiting, since it is practically a necessity for QoS.

Yes SamTzu is the same issue and here we don't run Squid…And i think is a generic issue but i believe still not fixed

LOL  ;) I should have mention it, I upgraded to 2.2.1 after my first post, delete the existing traffic shaper rules, and re created them

@Nullity: @Harvy66: Don't forget to set the bandwidth on the interface. You should set it to a value slightly less than your actual upload speed. If you get 5Mb to say speedtest, then set your  upload to 4.9Mb. It also depends on the stability of your upload. If it fluctuates a lot, you may want to lower if further. In theory, you should set your interface to be less than your lowest speed, but that is not always practical. The emboldened section of the quote is very important. If pfSense is not the "bottle-neck" of throughput, then traffic-shaping does not work. You might try setting qACK to ~500Kb and set other (unimportant) queues to 1Kb. Leave m1/d/m2 alone, for now. Perhaps try check-marking the "Codel Active Queue" box. Regardless of the algorithm you choose (HFSC, CBQ, PRIQ, etc), you need to follow standard QoS practices and understand a good amount of networking basics. I quickly found out that "easy" and "QoS" rarely coincide, sadly. <- What he said  ;D There is no easy money in this… but this golden link helped me with basic understanding of QoS: http://www.linksysinfo.org/index.php?threads/using-qos-tutorial-and-discussion.28349/ If you read all of it... you can go further. I also thought that using basic pFSense wizard would get me covered but...

State table uses 10% of RAM by default, but you can modify this as per SamTzu. https://doc.pfsense.org/index.php/How_can_I_increase_the_state_table_size