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

5.2.JPG 5.1.JPG 5.0.JPG 4.1.JPG 4.0.JPG 3.3.JPG 3.2.JPG 3.1.JPG 3.0.JPG 2.1.JPG 2.0.JPG 1.3.JPG 1.2.JPG 1.1.JPG 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. 😉

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.