@
Supermule Just a heads up - the stateless video you posted in the other thread wasn't stateless. It was using 60% of 2,000,000 tables at peak.
If you haven't already done so - substantially lower the states per host, state timeouts and limit connections per second.
-Set the actual timeouts lower -Some services can handle very low timeouts, some can't ->experiment with it.
-Set the adaptive timeout start point much lower.
-Limit simultaneous connections per client
-Limit states created per host
-Limit the number of "new" connections allowed per second - be cautious with this one.
The limiting options per host and per client won't always help if the attack is coming from a large number of actual sources - or is simulating random source's. So running lower settings for .first, .established and friends
https://www.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5 +new connections per second can pick up the slack.
The above limiting rules may not work with all types or protocols. So making multiple rules might be needed. And look into using "Float" rules in pfsense + the quick pf option.
For faster NAT you can also try: net.inet.ip.fastforwarding=1
There's a few caveats
https://wiki.freebsd.org/NetworkPerformanceTuning
-I apologize if I've posted anything you've already tested. But between both threads there's been hardly any information posted. I understand and respect your reasoning for not posting the script or exact attack type details. It makes sense, and frankly I'm glad it wasn't posted publicly.
However not posting things like the sysctl.conf, pf.conf, hardware specs as well as any settings you've already tried + those results, makes getting a helpful response nearly impossible. Videos of a gui don't really cut it. Especially if inaccurate.
-And as I'm sure you're aware none of this will stop a massive multiple source attack.
@
Remington
Sorry if I derailed your thread m8. Hopefully at least some of this is helpful.