The current Snort package on pfSense is based on the Snort 2.9.11 binary, so it is single-threaded.

I had every rule set checked just for testing purposes. But now i will check out if changing IPS policy will do a big improvement in my network. Thank you so much for your help, cheers!

@derpy456789 said in Potential Suricata Inline Netmap Solution: Hello NollipfSense, Just wondering what kind of system/specs are you running suricata inline on and also did you change any setting inside the interface setting of suricata like the Detection engine settings for max pending packets ? Ive been getting the same error netmap_grab_packets bad pkt Thanks Sorry for the late reply...I am running an HP Pavillion a6242n with Intel 82575 NIC 8GB RAM.

I suspect there's something wrong with inline mode as we've had cases where traffic doesn't flow but no alert is logged. See https://forum.netgate.com/topic/131572/moved-suricata-from-wan-to-lan-can-t-remote-desktop-in/10 https://forum.netgate.com/topic/109581/suricata-inline-whitelisting/8

I think I may have found the problem by uninstalling snort and trying suricata: After installing suricata, same problem happens. Then I tried an older version of the snort rules: snortrules-snapshot-29110.tar.gz works snortrules-snapshot-29111.tar.gz causes firewall to crash! So, something is definitely wrong with the pfSense code... a content update should not crash the firewall!

This is a wild guess but does your router have a file named /usr/local/etc/suricata?

@cukal Using Suricata wasn't all that scientific...we had to start somewhere, Suricata is multi-threaded and Snort isn't, and there were packages for both so we tried one. As I vaguely recall Suricata was developed by OISF as something of a next gen Snort, and it's compatible with Snort rules. Search "snort vs suricata" and you will find a bunch on it.

@vacquah said in Best way to block some gaming sites: Fortnite Your best bet would be to sniff to see exactly what is being used for this game, the fqdn that are being queried for, and or ports used, etc. More than likely this is hosted on some CDN somewhere.. My guess would be AWS. Then sure a simple host override on pfsense dns to send this fqdn to nowhere, ie loopback or 0.0.0.0 or even sure somewhere that presents a info page on 80/443 to not use company bandwidth, etc. Only problem with dns blocking - is you have to make sure your clients can not use some other sort of dns to resolve it. So you have to force all clients to use pfsense via dns redirection, and or only allow dns to pfsense and block all others. There is always away around.. You could tunnel out on 443 for example, you could use dnscrypt via some open port, etc. But a dns block and or simple blocks of the ports it uses if they are specific and not standard ports like http/https can stop the vast majority of typical users. Problem is once user figures out how to bypass your restrictions it spreads fast!!! Content filtering and or blocking is normally always an uphill battle that is hard to win.. If users want out, they normally can find a way. This day an age though users just going to play the game on their phones via their cell connection. But atleast then they are not using company resources and bandwidth ;) Good Luck!!!

@chudak said in snort (SID 43687) blocks root DNS servers ?!: @bbcan177 would it make sense to black list all top domains listed here https://www.spamhaus.org/statistics/tlds/ ? Its not a one-size-fits-all... Most of those TLDs most users will never need to access, so I would see little issue. There is also the TLD Whitelist, where you can allow some specific domains thru that are being blocked via TLD Blacklist. There is also this TLD list: http://toolbar.netcraft.com/stats/tlds

This happened to me, and I tried: DID NOT WORK: Forcing updates to get new MD5 hashes. Some updates had failed, and this made the "Result" Success again. However, the non-starting symptom continued. WORKED: Change the time of the day when updates occur. This did the trick for me, and I haven't had any problems since. Not sure exactly what the problem was, but the non-starts were occurring on only one of the scheduled update times. It was 0:05 and 12:05, changed to 8:45 once a day and have had no problems for two weeks now. I'm changing it back to two updates a day, but keeping 8:45. Hope it works.

@trumee I think we ended disabling the entire stream-events.rules ruleset to avoid these errors. IIRC if you are in legacy mode the packets can be scanned out of order and trigger false positives.

It would be interesting to keep a forum sticky as to what hardware this works for people on, I have the Intel i211AT on the pcengines APUC4

Nobody has an idea to help me?