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

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
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
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:-)