Firewall - Traffic Shaper - Limiter That's all a limiter does; it limits the incoming or outgoing traffic to a specified rate.

@chercheur: @Hollander: Thank you once again for your most excellent, and too kind, help, Georgeman: I am in your debt  :P I tried it again, and you will guess it: it doesn't work  :-[ [/quote] Hello, Did you manage to get this finally working ? I'm interested because I'm only using basic rules for my VoIP … that are working. Tx ! What I want not yet, no. But I have reasons to believe shortly it will work. But the default traffic shaping is working (again, I wanted something a little bit different). So you might considering trying the default; simply go through the wizard and raise the priority for VOIP, and then see what happens. Perhaps this works for you too  :D

Same with me. Even the RRD graph shows bandwidths of 600Mbps. I only have 100Mbps. [image: RRD-queue.PNG] [image: RRD-queue.PNG_thumb]

@GomezAddams: Is it as simple as creating a floating rule at the end of the rules that matches every tcp packet and sends it to the qACK/qDefault queues? Yes, on interface WAN, direction OUT (considering that you want all your TCP traffic on the qDefault queue and no further classification)

Are you using the traffic shaper?

You said you have only 1 LAN, but you mention you have multiple subnets. What do you mean? Are you using VLANs?

It's OK, the limiter will be applied to whatever gets catched by the rule, and incoming NAT traffic won't.

Thanks fixed my problem.

@GomezAddams: @georgeman: Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing) What does selecting an ack queue do for UDP traffic (since UDP doesn't have acks)? Not really sure. What I can tell you is that some traffic might be catched, depending on the packet flags I guess. To make sure everything works the way I want, I prefer to create two rules: one with acknowledge queue for TCP, and one without for UDP

No, there is not currently any way to do that.

That is a known issue that was fixed in 2.1.

Could I most politely ask if what you mean is actually the qACK below root_pppoe0 that needs to have a QLEN > 0? Yes, I can hear you. The answer is no.

Any help on this would be greatly appreciated. Thanks.

Hey georgeman, I get what you're saying, trust me I'd love to do one floating rule, but I found this during my testing and research of the settings. https://doc.pfsense.org/index.php/Traffic_Shaping_Guide#Setup_Limiters “pfSense currently only allows setting the source address or the destination address as the mask, meaning that you can give each host behind your firewall its own set of pipes so that each node is restricted to using a certain amount of bandwidth. To do this you would give your In pipe a Source Address mask, so that each host sending packets gets it’s own dynamic pipe for uploading. You would give your Out pipe a destination address mask, so that each host receiving packets gets it’s own dynamic pipe for downloading.” Also on the mask config in the pfSense GUI it reads: If ‘source’ or ‘destination’ is chosen, a dynamic pipe with the bandwidth, delay, packet loss and queue size given above will be created for each source/destination IP address encountered, respectively. This makes it possible to easily specify bandwidth limits per host. My understanding of these documented statements is that the limiter can limit upload for each LAN –> WAN session (source), or download can be limited for each WAN –> LAN session (destination). When I tried using the mask source configuration, I saw my steam client download from multiple remote sites which, broke the whole concept of limiting download bandwidth for a single LAN IP, as I need to limit the sum of all download connection sessions. It worked for single streams of traffic to single IP addresses, such as with speedtest, but not for downloads from multiple remote sites. Either that or I configured it wrong. I tested with the new limiter config using the mask for source, made new rules, and one machine still topped out the qHTTPandSteam queue. Let me know if you find testing to be different in your environment.

Interesting.  I happened to remember my pbx is set up to set diffserv/tos bits on RTP and SIP packets, so I deleted the shaper and created a new one with 'generic(lowdelay)', and the 2 floating rules were replaced by 1.  I just tried making another call, and lo and behold queueing.  This is probably one of the most frustrating things about using pfsense.  I really love the thing, but there are some aspects that are black juju, and it is more than a little frustrating.  You google for stuff like this and find literally a score of different articles, many with incomplete, wrong or contradictory advice.  Sigh…