@KOM: You could try getting the ASN for Googlevideo.com/YouTube.com perhaps and then shape all traffic from those IPs. Yes that crossed my mind but I thought it might not be reliable to rely on IP addresses as they might change. But it looks like it is the only option

It depends on the limiter. If the limiter is not masked, then it's one bucket for all traffic reaching the limiter, no matter what rule sends traffic there. If you put a mask on the limiter, for example a /24 mask, then it would work as a "per-subnet" limit so each separate subnet would have a different bucket of the declared size. So unmasked 30 Mbit/s limiter = 30 Mbit/s total /24 masked 30 Mbit/s limiter with two different subnets = 60 Mbit/s grand total, 30 Mbit/s per subnet.

It was never an issue except when I turned on Codel on the queues.  If I left it off , it ran fine.  It was mainly the torrenting that caused me to change tactics. Since you can't really block them the easiest and fastest fix is to limit them.

https://redmine.pfsense.org/issues/6836

@shapoval: Working (for me on 2.3.2) by simply adding a LAN rule at the top, Destination, Any, From (other) 3128 to (other) 3128 Custom. Credit to: Adrea Guglielmini http://guglio.xyz/pfsense-2-3-limiters-and-squid-bugfix/ It really works. Thank you for your message.

I little study and did this. 1. setup shaper with wizard 2. edit Traffic Shaper/By Interface. Click on LAn/DMZ/Wifi and edit Bandwidth (LAN,DMZ to 1Gbps, Wifi to 150Mbps) 3. edit LAN/DMZ/Wifi qLink. Click on LAN/DMZ/Wifi qLink and edit Bandwidth (LAN,DMZ to 1Gbps - 15Mbps = 985Mbps, Wifi to 150Mbps - 15Mbps = 135Mbps). 15Mbps is my internet download speed 4. apply settings,  reload firewall rules. I dont know if it is ok, because i dont know what set to "Queue limit in packets" in qLink. [image: lan_dmz_qlink_edited.PNG] [image: lan_dmz_qlink_edited.PNG_thumb] [image: wifi_qlink_edited.PNG] [image: wifi_qlink_edited.PNG_thumb] [image: lan_dmz_edited.PNG] [image: lan_dmz_edited.PNG_thumb] [image: wifi_edited.PNG] [image: wifi_edited.PNG_thumb] [image: wifi_qinternet_not_need_edit.PNG] [image: wifi_qinternet_not_need_edit.PNG_thumb]

@Harvy66: HFSC gives you strong control over bandwidth distribution while allowing other classes of flows to use spare capacity. I have a pretty over-powered system of an i5 3ghz quad and Intel i350-T2, and I'm only seeing about 10% cpu usage when running at 2Gb/s(1Gb full-duplex). Even when I used iperf to forcefully push 960kpps 64byte UDP packets, I was only seeing about 7% cpu usage. Seems UDP is much easier to process than TCP, probably because of the state validation. The network card is the single most important part. The second is the CPU. You really don't need a high frequency CPU, just one with a decent amount of cache and not something like an Atom that has been aggressively optimized for low power. My next system, whenever that may be, will target 2.5ghz and 8 cores with decent cache. Thanks for the info, HFSC sounds like what I need.  I'll have to read up on it, whether traffic is prioritized by DSCP tag (fine for outgoing as I control the tags) or port number and/or IP address (incoming, can't rely on DSCP tags). All the sub-kilobuck appliances sold at the pfsense store use flavors of Atom like the SG-2220 or SG-4860.  I'm not sure I need any more ports than WAN and LAN, as I have a Netgear GS716Tv3, which I think can do VLAN for traffic segregation.  If I could figure out how to use it. What do you think are reasonable CPUs for QoS-ing the entirety of 250Mb or greater cable connection, if not the Atom appliances?  I do use VPN occasionally, although highest performance here, while nice, is not a huge deal.  So I would want a processor with AES-NI also?  Intel NICs are a given, from what I've read. Thanks for the help,

@Nullity: The restart likely worked because it reset the states, which you can do without restarting by going to Diagnostics -> States in the pfSense GUI. That was incorrect of me. I've just restarted the modem and everything was fine. During the configuration I've resetted the states several times on the pfsense machine.

VOIP traffic likely needs to be prioritized with traffic-shaping. DMZ or port-forwarding is likely a non-issue since these things would only help if the VOIP was non-functioning. Since VOIP is functioning, but not functioning optimally, it likely needs to have the proper bandwidth allocated with traffic-shaping.

@Nullity: @AbdulCebbar: @vesikk: https://forum.pfsense.org/index.php?topic=63531.0 Follow foxale08's guide on that page for what you want. That's what I used to achieve what you are trying to achieve. That config was working, after one of the pfsense updates there was an alert saying layer 7 limiter won't work anymore. And it didn't work. Now there is no guide to do it in new version. Limiters have nothing to do with layer 7. foxale08's tutorial should still wor,,k. Ok it's working but now my nat reflection is broken somehow, is this related?

I'm going off of memory, but I noticed qACK and other realtime queues only have realtime set. You may also need to set the non-realtime bandwidth.

Ok, I have reset them, but same problem still exist: All traffic goes to qACK, I would have expected to see the Mbps going to qIPTV queues. All traffic is in the interface LAN only? I would expected that all queues on the WAN would have higher speeds comparable with the sum of all LAN's? Screenshot attached while recording a HD program. No other computers are running as nobody is home at this moment: [image: 1.jpg] [image: 1.jpg_thumb]

Unfortunately, it will not filter all traffic from my lan it seems to work but it takes some time to filter traffic ( it needs a few second to reduce traffic ) but in the end it works

since I have no idea if the IP address changes or if it's load balanced, etc Ask your VoIP provider.  It's not a secret so they should have no trouble telling you the exact IP addresses or ranges they use.  Make an alias and then use the alias as your SIP server. Why is VOIP different? Those other options link to rules involving a specific port used by those particular devices.  With a generic provider, you must specify the IP address.  If you know that all your phone traffic uses port 5060 for instance, then you could craft floating rules that trigger on that port instead of needing to use a source/destination IP address.

Sorry SSP, had notify on but somehow missed ur first reply. No, I never did get a response and haven't had time to revisited the issue without something to go on. So glad you took the time to test actual behavior of the dynamic limiter. Odd the limiter screen shows buckets being shared.

If I understood correctly (sorry, TL;DR), your problem is that you are applying the rules on the LAN interface. In this case, it is best to create floating rules with direction OUT, on each of the WANs. It does not matter how the gateway groups or the routing are configured. Whatever gets OUT of the specified WAN, will go into the specified queue, period. Of course you will need two "trees" within the shaper, to accomodate each of the WANs My general advice is to always tag traffic with floating rules direction out on the proper WAN interface

Traffic within the tunnel is seen in and out of the "IPsec" interface as far as the shaper goes, not your WANs. The wizard is completely broken, I would suggest to configure everything manually. Best regards!

I'm still around, glad that post is still useful ;D Not sure about LAGG, but with regular VLANs I found the best way is the following (call it bug or feature, you choose): Send LAN1 traffic untagged Send LAN2 traffic tagged as some VLAN Send any other LAN network traffic tagged as well Then, from a shaper standpoint, you will see all the traffic from all the VLANs on the LAN1 (untagged) interface Yes, I know, some networking purists will complain that you should not send untagged traffic on a trunk, but it works If you choose to go with something like this, you need at least two separate physical interfaces, one for your LAN VLANs and another for your WAN VLANs

The shaper is messed up in many ways, this is one of them. This "bug" could easily become a "feature" if you have two physical interfaces and you run your WAN VLANs on one of the them and your LAN VLANs on the other. This "traffic grouping" you see is the only practical way to achieve proper multi-LAN shaping (when you have multiple internal networks, you actually want all the traffic on the same parent queue, from a shaper standpoint)