Could be a number of reasons. The firewall states are already open. Did you clear any matching states. The subnets are wrong. The traffic is initiated in the other direction. There is no matching traffic. Also is there any reason you're on 2.3.5 when you have 64bit hardware? Steve

If you can match that traffic with a firewall rule you can put it in a lower priority queue. Or you can match other traffic and put that in a higher priority queue. It's most effective for upload though since there you are directly queuing traffic leaving your WAN. Steve

PRIQ is a simple system based on priorities. It doesn't require you to fiddle around with limits and bandwidth allotments. You set priority levels for your child queues and then direct IPs or ports into the desired priority.

Main thing is to check to see if things are in the right queue while debugging. check (pfsense IP)/status_queues.php while a few torrents are going full bore, and ensure that the traffic is in fact going to the correct queue, and you should see drops in the p2p queue while you surf and such. If you don't see anything in p2p, then you likely have an issue with rules. Issue is the people with torrent ports in stupid ranges, or things landing in default queue because they didn't match the rule. I ended up making a small seedbox VM for whatever distro I'm messing around with and just making 2 blanket rules at the bottom of my floating rules (after default rule): match any tcp/udp from ip_distrobox to any match any tcp/udp from any to ip_distrobox Works like a charm after that. Not sure how else to get torrent boxes to shape right because they generally randomly pick ports to operate.

Just ran into this issue. When the Limiter is disabled, you will be unable to determine it is actually set on a Rule. Enable the Limiter, and you'll be able to find it on Rules and remove it.

This is probably the best place to start: https://docs.netgate.com/pfsense/en/latest/book/firewall/rule-methodology.html

Unless your coffee pot is networked - then it too should be updated! Do you not update your OS or your virus scanner software?

@tman222 Thank you. This was the failure. Now it works.

A further test comparing https using curl and netcat also on port 443. curl https works as expected with the traffic on the "low" queue [image: 1570783525281-screen-shot-2019-10-11-at-10.45.04.png] using netcat on port 443, traffic is sent to the default queues. cat bigfile.dat | nc myhost 443 [image: 1570783658208-screen-shot-2019-10-11-at-10.47.25.png] And the log files show the same rules are being hit in both cases.... Lan rule 1570715403 sets the tag. Floating rule 1570687650 on the WAN interface assigns the queues..... curl - filter.log Oct 11 10:51:55 pftest1 filterlog: 74,,,1570687650,em0,match,unkn(%u),out,4,0x0,,63,17834,0,DF,6,tcp,60,10.10.192.2,193.198.104.3,57884,443,0,S,2068721621,,29200,,mss;sackOK;TS;nop;wscale netcat - filter.log Oct 11 10:49:06 pftest1 filterlog: 74,,,1570687650,em0,match,unkn(%u),out,4,0x0,,63,49798,0,DF,6,tcp,60,10.10.192.2,10.10.32.158,41816,443,0,S,3570078997,,29200,,mss;sackOK;TS;nop;wscale From what I know these two look identical. So why would pf react differently to these?

@manu77 , I have selected the appropriate wan interface in each rule (in-rule and out-rule for each wan interface) - in the WanIn/Out rules I have selected only the wan interface, and in the corresponding wan2 rules I have selected only the wan2 interface. Good luck with any further testing:-)

Hello All, Somebody has found a solution ? Another topic is near this one . I tested exactly what you 're speaking about wihout any success !! https://forum.netgate.com/topic/140609/problems-with-flexible-limiters-set-using-floating-rules thanks

Hi @RedDelPaPa - It depends. How fast if your internet connection? If you have a higher speed connection a queue size of 50 might just be too small. If you do end up increasing the queue size, I would recommend also enabling queue management using Codel to make sure that you don't end up with bufferbloat. Having a high priority on the queue's traffic will naturally mitigate some of that, but enabling AQM will also help. Hope this helps.

This question might be better asked in the pfBlockerNG forum.

Limiters would be difficult to use here since I'm not aware of a way to have those dynamically adjust based on some type of feedback mechanism (e.g. latency, bandwidth, time of day, etc.) You might try some ALTQ traffic shaping algorithms / techniques instead to prioritize traffic accordingly. Here is some more info on that: https://docs.netgate.com/pfsense/en/latest/trafficshaper/traffic-shaping-guide.html https://www.youtube.com/watch?v=rF46PNid1Mo (long but worth watching) Hope this helps.

Sorry to bring up such an old topic, did you manage to resolve the issue?

Status > Monitoring is your friend there.

If you have created VLAN-based networks and assigned them to any LAN interface (ix0-ix3) but also assigned any of the interfaces directly (for example, ix0 for VOIP), the ones used directly will be excluded from the Traffic Shaper Wizard. The solution is to use VLANs only but leave all interfaces ix0-ix3 unassigned. This seems to be the case for SG-5100 but not for others like SG-3100 (I have both). Mixing of VLAN and direct assignment is not recommended due to security implications, but why it is excluded from Traffic Shaping wizard I am not sure. It seems to be allowed for SG-3100 although it does have a separate switch so it may not be apple-to-apple comparison. NOTE: The above is what I had to do in my setup; if you don't use VLANs though then the above would not apply and something else would be to blame.

I added some DNS exceptions rules in front of my shaper rules : [image: 1567088623012-dd8edc61-e2d9-4177-be57-4adf0fca8afb-image.png] The first rule is matched when unbound connects to any DNS server on the net, using IPv4 or IPv6, UDP or TCP, destination port 53. The second one matches when unbound send s out some DNS traffic on my LAN interface, source port is then '53'. (Destination could be anything above 1024). The counters show that these rules are matching traffic. Said all this, I still think your issue isn't shaper related. Unbound can't connect to "192.168.4.59 - port 1855" : it could be anything, even hardware related.