Prioritize the destination port and/or IP of the VOIP traffic.

Check: https://doc.pfsense.org/index.php/Limiters

@Harvy66: If you laptop was conencted via wifi, Window may have been load balancing LAN and WIFI, which if they had separate IP addresses, would get different buckets. Just a random thought. thanx, but limiter has 4 MBit for all pcs, not per single host. and in 99% of time it's working. and i'm sure that connection was only via wifi, there no physical opportunity to be simultaneously in lan and wifi. i found another thread in this forum with problem on vmware and shaping. May be it's similar issue. probably this is due to virtualization on hyper-v 2012 (not R2) and some unusual internal methods of getting w10 image from w8 side. May be a lot of active connections on 80 ports from single host. another problem is that i can't reproduce it at all, but it was twice.

You might get more help if you post your question in the Traffic Shaping forum.  Honestly, I don't know how you make it past all of the actual Support forums, all broken down by category, and end up posting your problem here in General Discussion.

Yes.  For floating rules, last match wins.  For all other rules, first match wins.  You can change this behaviour with floating rules by editing the rule and checking the Quick checkbox.

@mhertzfeld: Question. Since the VPN traffic passes through the WAN to get to the VPN provider, would shapping on the WAN and the interface used for the VPN cause issue? Would shaping the traffic on the WAN be enough when using CoDel? If you want to shape all aggregated VPN traffic, shape on the WAN. If you want to shape individual traffic types within the VPN, shape on the VPN interface, but any shaping done here will additionally be shaped by the WAN. (I'm unacquainted with VPNs, so be wary of my advice.)

I would highly recommend that you upgrade your unit to 2.3.2. https://doc.pfsense.org/index.php/Limiters YouTube has some How-To videos, a quick search shows lots of articles on the web about using limiters. #2 is hard because BitTorrent was designed to avoid filtering and use as much bandwidth as possible (by default).  The only way to avoid it without expensive DPI would be for you to classify every traffic type that you expect to see on your network and block all else.  Even that can be gotten around by using port 80 for your BT port, for example.

Hi guys, sorry I've been a bit flat out and off the air for the last few days. Firstly, thanks heaps for the help so far :) To answer "How does a single interface have multiple "links"" and to clarify my goal for Nullity, what I mean by that is that we have one interface for each client, but a single client might have multiple remote sites. In that case, we have multiple MPLS/PrivateIP tails being routed into one interface at the carrier/ISP level. So I'll have (as a loose example of what's happening, made up subnets etc.), OPT1 having an IP address of 10.1.2.6/29 which is a "hand-off" to our provider. the 10.1.2.1 IP is their side of the handoff. We'll then have three sites, Site 1: 20/20Mbit, LAN Range 10.100.1.0/24, WAN side is Hand-off to ISP on 10.1.3.0/29 Site 2: 8/8MBit, LAN Range 10.100.2.0/24, WAN side is Hand-off to ISP on 10.1.3.8/29 Site 3: 25/10MBit LAN Range 10.100.3.0/24, WAN side is Hand-off to ISP on 10.1.3.16/29 On each handoff the first IP is the ISP end, last is the site end. On the site routers their default route is the ISP end of their handoff, the ISP then has a routing table on the VRF for that client which points everything back at the 10.1.2.6 IP on OPT1 on our router, and points each of the site's subnets back at the relevant router. On our router we have a static route for each of the site's LAN range (10.100.[1,2,3].0/24) pointing at 10.1.2.1, the ISP then routes that to the router on the relevant site. So my issue is that I have three sites/links, each with different speeds, terminating on the one interface on our end and I need to do some sort of QoS to each of them so the root queue speed is the issue I guess. Just thinking out loud… if the interface/root can be set to "100%" (or total of links), then have a second level per site, then the queues under it, that would probably work, but I don't see it letting me create a multi-level hierarchy...

If you are using HFSC you can set a minimum bandwidth as well on the queue , that way those queues will alway have that bandwidth available to them versus a max and then a sharing amount. I typically set qGames and aHTTP at 35% each with qGames getting half of that as minimum. That leaves 30% for qACK  and qP2P (Default). Granted this is at LAN parties as well where I only really care about Gaming traffic. I use alias's for the gaming ports as well.

Change your second rule so that the Interface is WAN, not LAN.

The internet is very bursty, which can add to jitter. One of the nifty things that Google et al have done is added bursting to TCP to help combat latency and slow-start. It is common for TCP windows to start at 10 or greater. With 1500 byte segments, that's almost 15KiB of data. Now throw in browsers trying to load over several connections at the same time, like 10. You're now up to about 150KiB of data that can be bursted at you with 10Gb/s+ rates. That's about 12ms of data at 100Mb/s. Maybe it won't matter in your situation, but I would be very aware of transient issues that could make your VoIP have issues that are perceptible to humans, but difficult to measure as issues like with IMCP

@Nullity: Ah, I see. Sadly, the answer is "No" then, unless you want to some scripting yourself. Linux iptables does have this feature built-in. FYI, gb = gigabit, gB or GB = gigabyte. I just spell it out to avoid confusion. Ok, thanks for your reply and clarification.

That is because limiters are applied when a state is created, which is done on WAN, not on LAN. But due to a long-standing limitation, you cannot place limiters on the same interface as NAT rules. Try making a floating rule. Action: Match Interface: LAN Direction: Out Source: any Destination: 192.168.0.17 Destination port: 80 In/Out pipes: Your limiters Note than on a rule on an outbound interface the direction is reversed so In will be to the webserver and out will be from the web server. I think. It's confusing. If you get it backwards, flip them. Note that that will catch traffic in both directions on inbound connections to your port forwards. You do not need the rules on LAN. If you want connections made BY the web server, not TO the web server to not be limited, just remove the limiters on LAN. I do not know for sure if this will escape the NAT+Limiters bugs but I think so. Be sure to use interface LAN (or your web server's interface) direction out.

Current supported list is here: https://github.com/pfsense/pfsense/blob/master/src/etc/inc/interfaces.inc#L5657 I don't recall enc0 being specifically removed, but if it's not in the list, it must not support ALTQ any longer. I know it did at one time, probably 2.0.x or before, but not now apparently.

Thanks Harvy66, The ping of my Teamspeak and Pinging Google is staying a lot lower now. Thanks for the your help. Ping looks like this now, (See Screenshot) Done while downloading 1GB Bin. on my 37/2 connection Many Thanks EDIT: Watching a youtube video and its unless stable, very odd. See second screenshot I noticed it says 40mbps but the queue is limited to 36864    

Redid it with out the . and worked fine.

There isn't any way to see that information. The best you can get is the pftop "queue" view or the output of "pfctl -vvsq"

And powerboost only applies to free bandwidth on the node. There is no way for you to know that.