Have you got a new version. Because i have got a problem with DNS Thanks

If this is right and if I corectly understood: https://calomel.org/pf_hfsc.html CBQ and PRIQ type queues with a higher priority are served first if the link is saturated and the "realtime" bandwidth is also exhausted. PRIQ is doing the job from the moment the queues are over the size of the connections Queues systems, when in use induce latencies Don't forget I'm on VDSL, asymetric connection without garenteed (?) bandwidth Let's get the following exemple: Good days: 75Mbps Down/6MbpsUp. Average:  50Mbps Down/5MbpsUp. Bad days:  25Mbps Down/2,5MbpsUp. If the connection speed is set to high value 75Mbps Down/6MbpsUp and the real value of the connection is under (for example 50Mbps Down/5MbpsUp): – If my needs for connection are under the real connection capacity (50Mbps Down/5MbpsUp. ) : no problem -- If my needs for connection are between the real connection capacity and under the value of my connection as declared (75Mbps Down/6MbpsUp): problem: PRIQ will not trigger and my VOIP can not function with quality. The network is consuming all the bandwidth so VOIP will sufer, the priq will not work because it will only work when my network is filling connection queues with 75Mbps Down/6MbpsUp -- If my needs for connection are over my connection as declared (75Mbps Down/6MbpsUp) : PRIQ will triger, VOIP will work with may be a bit latency due tu queues system. So IF I set my connection too high I risk PRIQ not to work when the needs for connection are between the triger and the realtime values of the connection. If I set my connection too low, trigger will often work (when not needed) and PRIQ will work (when not needed) and induce latencies. Is it right?

also the game runs on a 60 tick rate , do i have to adjust the d

@nils92: …but they might be related to the fact that I run everything through a VPN which I can't seem to traffic shape on. If you're tunnelling through the PFSense with a VPN connection, as far as the PFSense is concerned all the packets passing through the VPN are destined to the VPN server (assuming an outbound connection), not whatever they go to once they pop out the other end of the VPN. So you're correct - you can't shape traffic within a VPN.

@moscato359: I had the same problem with sch_codelq, but sch_fairq with codel fixed it I have the same problem (500/30 without shaping goes to 250/20 with codel shapers set to 20 for wan and 480 for lan) Tried fairq shaper with the same result. What is sch_codelq and sch_fairq? Is this the same as codelq shaper and fairq shaper in the gui?

https://forum.pfsense.org/index.php?topic=126637.0 See this thread

Yes it's a simple validation issue.  I also have those illegal priorities set due to numerous upgrades going back to 2.1.3 when it used to work.

@Nullity: @davidmoore: @KOM: For floating rules last match wins (the Quick option is unchecked), so putting your rule at the top may be part of the problem.  Also, you need to clear states before the change takes effect. Okay, so I read more about this and floating rules still do topdown processing, but it will choose the last rule that matches in the list unless Quick is selected. If Quick is enabled then it will stop processing that packet and go ahead and make the match. I have quick enabled on that rule and it's at the top of the list. According to https://doc.pfsense.org/index.php/What_are_Floating_Rules (at the bottom of the page): "Rules using the Queue action do not work with quick checked." Thanks. I think this issue is resolved.

I'd turn QoS off, and run a dslreports test

I have the same issue I can apply the traffic shaping on the Lan interface but that will also cripple local speed e.g. SMB

Hi jimp, thanks for your reply. I tough i saw the interface WAN before creating the VLAN but I maybe mistaking. I will try to find another machine to setup my pfsense than. Thanks Sebastien

@Nullity: @moscato359: If I use limiters, how do I get fairq, codel, etc? Not with 2.3 (AFAIK) but 2.4 has fq_codel in limiters, which I'm looking forward to using. Even though limiters currently lacks any sort of AQM it still might be worth trying. You can also do proportional, per IP bandwidth sharing with limiters: https://forum.pfsense.org/index.php?topic=63531.msg364520#msg364520 I dunno if that works with multi-LAN though, since I think it requires a subnet mask. Can you mix limiters and altq together? For example: wan 20mbit altq, 150mbps incoming limiter lan1 altq 150mbps lan2 altq 150mbps lan3 altq 150mbps lan4 altq 150mbps Would that work?

I think I had a setup similar to what you're asking. I had dual NIC that I used for LAN and WLAN but also wanted to limit traffic. I used Foxale08's traffic limiting guide for the single LAN and just set it to both the LAN and WLAN Interface. It worked great and didn't show any problems but I no longer run that setup and simply use Foxale08's guide on a single LAN interface until I get VLANS setup. here is the link to his post (it's about half way down the page) - https://forum.pfsense.org/index.php?topic=63531.0

Internet speed, and it's from the perspective of the interface that is transmitting Wan is your internet upload speed, since wan transmits upload Lan is your internet download speed, since lan transmits download

I was in the same boy, I wasn't trying to shape full 10gbps, but rather just 2gbps. I'm not able to test this anymore, as we disposed of the Netgate tested Chelsio cards.

I think the bandwidth limit is solely determined by the interface the packet will leave from. So in my case, packets from the local network destined to the internet are controlled by the bandwidth limit of the scheduler on WAN (22.5Mb), and packets from the internet destined to the local network are governed by the bandwidth limit of the scheduler on LAN (115Mb).

Harvy66, you nailed it.  I left the default queue sizes and didn't realize they were too small.  I guess pfTop must be averaging QLEN or something because it was rarely hitting double digits.  Bumping the queue limit to 500 (since I know qLink works with 500) gives me the results I was expecting.  It was the first thing I tried, so you saved me a bunch of time.  Thanks. moscato359, it helps to know the wizard might not be making the best choices.  When I'm trying to learn something I usually assume the defaults are well tuned and that if they don't make sense to me it's a misunderstanding on my end.  Also, thanks for the explanation regarding my 5th question.

It sounds like you several goals that are independent Start with ad, then get squid involved, then figure out traffic shaping

Your queue sizes are probably way too small. Network transfers are very bursty. Large buffers cause buffer bloat, but small buffers cause unnecessary loss. Or just enable "Codel" under your queues.

Harvy66, I hadn't thought of that, so I did so some looking. It appears by default OpenVPN does allow out-of-order packets with UDP. According to https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage: –replay-window n [t] Use a replay protection sliding-window of size n and a time window of t seconds. By default n is 64 (the IPSec default) and t is 15 seconds. When OpenVPN tunnels IP packets over UDP, there is the possibility that packets might be dropped or delivered out of order. Because OpenVPN, like IPSec, is emulating the physical network layer, it will accept an out-of-order packet sequence, and will deliver such packets in the same order they were received to the TCP/IP protocol stack, provided they satisfy several constraints. (a) The packet cannot be a replay (unless –no-replay is specified, which disables replay protection altogether). (b) If a packet arrives out of order, it will only be accepted if the difference between its sequence number and the highest sequence number received so far is less than n. (c) If a packet arrives out of order, it will only be accepted if it arrives no later than t seconds after any packet containing a higher sequence number. It could definitely create issues where starvation would cause packets dropping. I'm not saying what I'm trying is necessarily a great idea, but it would work if I could select different queues for different traffic on the same OpenVPN tunnel. Churchtechguy, I had thought of that. It doesn't scale well though when you have several offices though. The other idea that I had was traffic shaping the OpenVPN interface. If I assign the interface 10 Mbps, I can traffic shape the WAN and make a queue that matches the OpenVPN traffic and has 11-12 Mbps (OpenVPN interface wouldn't take into account overhead from tunneling). I guess there is several ways to solve this issue, I just don't feel like there is any good way right now with PFSense. Thanks!