@bobbenheim Looks like that was the trick, I can see the rule working choosing LAN for the Penalty users, thanks Sir.

@Kaila said in pfSense CE: I need to know if pfSense CE gives bandwidth use. If It does, how much is that? Yes, bandwith is limited to the hardware pfSEnse is running on. If you have x GB capable device, then that's what you get ^^ @Kaila said in pfSense CE: do we need any routers or servers to work with pfSense CE? Well, you will have to use some upstream "modem", or whatever other device that brings "Internet" to your site. But no routers or servers are needed.

On Linux I'd know a way, netfilter actually has a module that switches chain/rule after a certain amount of time, but on BSD I actually don't because I never had the problem before. Btw: Standards are a problem of their own. When stuff like HFSC gets implemented it doesn't necessarily mean it's following the whole standard. Always check the BSD docs on the corresponding version: https://www.freebsd.org/cgi/man.cgi?query=altq&apropos=0&sektion=4&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html Sadly I don't see a solution at this time, not with pf or even ipfw and limiters as there's no way to do anything based on time (e.g. 5 seconds). There are workarounds with tables and PF's match rule, but that's nothing you want in production. Cu

ue0 (USB Ethernet) does not support ALTQ.

@bobbenheim said in Log limiters: The more important question is what traffic are getting dropped and is it a problem? Yes, it could be the problem. For example: unauthorized application installed (P2P), misconfigured application, malware... etc.

Aaah, I have an alternative port... Thanks for the hint!

@PVuchetich2 that is a typo, i meant 20480 :) Update: tried upping value of flow and am not seeing any stability issues, though i am on 2.4.5 versus 2.4.4 p3 when i last increased flows. Also setting flows to 40960 gave a couple of ms less on upload bufferbloat in dslreport's speedtest. Download seems to be the same but cpu usage is increased by it.

@dzabdelhak according to the pfsense docs here you can set a weight on your child queues. I have not tested weights, but i would assume that if you set a weight of 50 for both queues it should prioritize them evenly when needed. It might be easier to set up fq-codel with a single queue first to mitigate bufferbloat and then add a second queue afterwards.

Maybe a part of answer here: https://success.alienvault.com/s/article/Why-does-a-TCPdump-of-my-monitor-interface-return-ethertype-Unknown In some environments, a physical or virtual switch can be configured to use VLANs on the SPAN ports the USM is connecting to. When using this configuration, the appliance will discard this traffic as it is unable to parse VLAN Trunking or other Bridge Protocol encapsulated traffic. This message indicates that the network stack is not capable of reading or interpreting the traffic showing this message. As this traffic cannot be read, it will be discarded. This issue can be resolved by configuring your physical or virtual switch to pass the mirrored traffic to the monitor port as IP traffic (ethertype 0x0800). In this context, does somebody knowss how to configure pfsense to pass the mirrored traffic to the monitor port as IP traffic (ethertype 0x0800)? Are there some security risks to do that? Thanks

@eshartle said in Dropped SYN packet: Any ideas what to check? For starters... Lets see the firewall rules. And simple sniff on pfsense to validate the syn gets to pfsense in the first place. And then just sniff to see if pfsense sends the packet on. How do you have this setup exactly? And how is stuff being routed? You have it between your lan segments? So clients don't point to pfsense as there gateway? Or these 2 networks are lan segments on pfsense, etc.

I've saved all of them when PFsense was an older version, but they should still be useful. Maybe someone applies them to the last pfsense version and take screenshots and uploads them back... [image: 1576926752983-5.2.jpg] [image: 1576926752971-5.1.jpg] [image: 1576926752965-5.0.jpg] [image: 1576926752958-4.1.jpg] [image: 1576926752941-4.0.jpg] [image: 1576926752934-3.3.jpg] [image: 1576926752917-3.2.jpg] [image: 1576926752910-3.1.jpg] [image: 1576926752892-3.0.jpg] [image: 1576926752875-2.1.jpg] [image: 1576926752859-2.0.jpg] [image: 1576926752851-1.3.jpg] [image: 1576926752833-1.2.jpg] [image: 1576926752825-1.1.jpg] [image: 1576926752806-1.0.jpg]

@Maxburn Unless you are using Pfsense 2.5 it works just fine setting up the rule on WAN, you can use this guide to set it up. If you go with fq-codel i would suggest you keep the stock settings as some of them, at least in my case, caused system instabillity. Other than that i would suggest using CoDel for the queue management algorithm in the limiter and tail drop for the queues, which also in my case kept latency more stable. It can also be necessary to lower the default value of limit from 10240 to something less on lower speed connections for fq-CoDel to work properly.

@alex42 I guess you would want dynamic queues which is mentinoned in the Pfsense Docs, you can specify traffic on specific ports to be send to the queue with a floating rule.

That is one way to do it. You could also set the queue on a floating match rule on LAN in. Or a simple pass rule on LAN for just that source host that is higher in the rule set than the pass rule for everyone else.

If you don't need per host limiting you could give this a go https://forum.netgate.com/post/807490 You do not need to do any changes to the fq_codel parameters and i would actually not recommend setting flows to 20480 as it makes my pfsense system unstable. But you could also just as easily keep using the scheduler you already are. Do not know why your setup isn't working as i haven't tested it, but the one in the link i at least do know works as i am using something similar.

@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.