I've found the cause of this error.  It is due to a change the Suricata team made upstream that changed how the TLS certificate storage directory was specified in the suricata.yaml file.  The fix will be in the next Suricata GUI package update. Bill

^^ that spawned a possible good idea - for the pfsense dev's, setting the minute number randomly, on first install, would help for the future.  You should expect to see a higher server load as more people use pfsense.

Yeah, to be clear this is absolutely wrong place to post. Noone here maintains the snort.org webservers so noone here can fix broken checksums they keep uploading over and over and over again. If you have a paid subscription, complain to the Snort guys, if you have none, then you get what you paid for and simply wait till someone fixes it.

It helped me.  Thanks!

@userjanuary2017: Oh wow, great news on pfsense reinstalling my packages automatically, thank you Bill, I really appreciate your help very much! As I said, I'm not 100% sure on that point, but I believe it used to do that.  If you have pfSense paid support, they can verify that point for you in case I am mistaken. Bill

@tiki1980: @bmeeks: I have abandoned the use of Barnyard2 on my personal firewall due to problems with it.  I wish it was more dependable, but the constant problems finally wore out my patience.  I was using it with Snorby. Bill Not really ontopic but what do u use as a frontend? I looked at www.aanval.com which has it's own proprietary shipping mechanism of the unified2 logs but this only allows for one sensor (really one interface) Since it is just my home network firewall, I am not currently sending the log data anywhere.  I just periodically review stuff directly on the firewall.  I have not investigated using anything else since I dropped Snorby. Bill

@pfcode: @bmeeks: As for the HTTP_INSPECT rules in Snort, I say this with some tongue-in-cheek – they will alert on pretty much any HTPP packet these days and have become darn near worthless becaue of that IMHO.  I have disabled the majority of those rules in my system. Bill Are you talking about LAN preprocs->Http Inspect?? Any of them to be honest.  A lot of them misfire (as in generate false positives and thus false blocks).  I know some of the rules might be OK, but many are either out of date or else a ton of legitimate web sites are sending out vastly screwed up HTTP traffic.  I just know that if you enable all those HTTP_INSPECT preprocessor rules you will immediately start to get alerts and subsequent blocks on a large number of mainstream and legit web sites. Bill

@dhboyd26: Thanks for the reply.  I should have thought about that possibility as much as I have been bamboozled by UNIX to DOS files before.  The lists were put in by hand in the GUI, so all is well. but for future reference (hopefully never) I will definitely check that. On a completely unrelated topic, since you are the maintainer of the package, I wanted to let you know that we now have Suricata running inline after a hardware change from Intel X710 adapters to Intel X520 adapters.  Been working like a champ!  Thanks for your work maintaining this package. Good to hear.  Netmap support is still not 100% in all the NIC drivers yet, but maybe someday we will get there. Bill

@bmeeks: If you uninstalled the package with the "Save Settings" checkbox unchecked, then all remnants of Snort were removed from your config.xml file which the firewall uses to store all of your configuration information.  So if you re-install the pacakge, it should behave as a 100% fresh install with no pre-existing configuration settings brought over. Bill Great. So i uninstalled the package and reinstalled it, didnt help. Installed suricate and it worked out of the box. So I made a passlist and used that for external_net in snort instead, and it worked. But now the "!" infront of the IPs are gone, exactly like the home_net. In other words it says that my external_net is home_net now , but it worked somehow. But when i added rules it stopped working again. So i tried to find out exactly why it stops working and i have somewhat narrowed it down to the "emerging" rules, when i add one of them, snort stops working. I have no idea whats going on anymore :P

Not surprising.  The latest 3.0_12 package just has two minor bug fixes within the GUI itself.  The underlying Suricata binary is unchanged and remains at 3.1.2. Netmap support will make it into more and more NIC drivers, but it will take a little time. Bill

wow bmeeks is back  now i forgot my issue that bmeeks can answer.

It happens to me as well. I just use service watchdog package to keep the service on automated restart in case it stops after the nightly updates.

Re-posted my comments to a new post as this one is about Snort. My bad…

Morning, any update on that package? As BBcan177 noted with his link above, I am creating a logstash-forwarder package for submittal to the pfSense Team.  If they approve, then you can use the new package to send Suricata and other firewall logs to an ELK (Elasticsearch Logstash Kibana) setup. Thanks,

"Additionally am I right in thinking that in order to block comms between LAN/OPT/DMZ interfaces, I need to specifically add in a block rule to block lan net to dmz net etc?" Well would depend.. Out of the box when you create an OPT interface pfsense puts NO rules on it, so everything would be blocked hitting that interface.. As to specific block rules and such.. Depends on what if any traffic you want to allow between your different segments and what direction this traffic will be imitated from Rule are evaluated top down on the interface they enter pfsense on.  First rule to trigger wins, no other rules are looked at.  There is an explicit deny at the end if no rules trigger on an interface then that traffic would not be allowed.  This is on every and all interface. " Am I right in thinking that my local device names will be passed up to the DNS servers up stream so to speak i.e. the OpenDNS servers. " No your not right in thinking that… Always just blows my mind how internet is useless without dns, and everyone uses it every single day on every single connected device they own.  Yet seems nobody understands even the basic concepts of how it works ;)  Just freaking blows my mind!!! If you want your clients to resolve your local devices by name and not broadcast for them.. Then you need to use a nameserver (dns) that can resolve them for you - ie pfsense.  Having a client ask opendns or googledns is not going to be able to resolve your local devices by name other than via broadcast.  So if those other devices are on other network segment that is not going to work!! Setting your clients to have 2 dns, ie pfsense and something public is not going to work because you can never be sure which dns your client is going to ask.  And it sure doesn't ask them in order or both at the same time, etc.  There are differences in depending on what OS your client is using..  But in the big picture your clients should only ever use nameservers that can resolve the same stuff.  If what your wanting is to resolve public stuff - then sure you could use opendns, googledns, 4.2.2.2 since any public dns can and should be able to resolve all public domains..  But they are not going to be able to resolve your local stuff. So if you want to resolve local stuff - then your clients have to ask your local dns.. You could get fancy and setup more than 1 that have the same local data.  But in your typical soho type setup there will be 1.. Pfsense if your wanting to run pfsense.. So your clients ONLY ask pfsense!!!  This is how pfblocker ad blocking works you have to be asking pfsense using unbound..  Now you can setup unbound to resolve, or forward.  If you want to forward to opendns you can do that.  But your clients need to only be asking your local dns first if they want to resolve local.  Then you setup your local dns to either forward or resolve.. If you have no rules on OPT, but any any on lan for example.. And LAN creates the connection to something in OPT, the state that pfsense creates would allow the return traffic. While I commend wanting to learn about IPS/IDS - unless you know what your doing its going to be very painful!!!  I would suggest you turn it on in MONITOR mode only!!!  This can report on stuff that it sees, but will not block anything.  This allows you to trim down the noise before you actually go into IPS mode..  IPS is not something for hey that is what a mask is, oh that is tcp traffic, and that is udp.. but really don't know what the difference is ;) pfblocker is a great package when used correctly and understanding what it does..  But to be honest it can be quite confusing to someone that is just learning about networking/firewalling/etc.. Letting it autorule shit is prob going to break stuff if you want my honest opinion, no offense bcan!!  Wanting to run an adblocker that is dns based without understanding how dns works is just asking for trouble if you ask me!!  Most likely going to break shit again!!!

Snort works on a copy of a packet, it doesn't block anything, it merely passes the offenders to snort2c table for pf to handle it. If you want an inline IDS/IPS, use Suricata. (Inline mode needs a supported NIC, plus I would not suggest this if you are using VLAN or shapers, see #6690 and #6023.)