@bobbenheim said in How to limit incoming packets per second per ip?: @NogBadTheBad Doing bandwidth limiting i can understand, packet limiting i can not :) Yup I'm not sure he actually means packet limiting

Woahhh. I tried your guy's solution and now I'm getting gigabit speeds! 946 mbp/s down!!!!!!! Actually what happened is a major networking fauxpas on my part. I didn't pay attention and assumed the applications on my PC were telling me Bytes (not bits) per second, like Steam usually does. And well because my download is 250 Mbits per second, that just happens to be roughly 8 times the 32 Mbps that I was actually getting on WAN. So embarrassing. I did manage to get my speeds corrected though. When I realized my WAN speeds were the culprit, I tried some of the solutions people usually suggest. I tried messing with the MTU, resetting the modem, resetting the switch, checking interfaces/limiters. It wasn't until I directly connected my PC to my modem to confirm I was getting the correct speeds, and then plugged the PC back into the switch that my WAN interface received the full download speed. As far as getting gigabit speeds, well that's because I upgraded my internet plan.

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?