Thanks Bill. I was wondering about that. I'll fix by doing what you suggest. Thanks.

No, there is no CLI debugging that I am aware of.  I had so many issues with Barnyard2 that I just stopped using it on my personal firewall.  It has not been updated in the FreeBSD ports tree for quite some time.  I don't have another alternative to suggest, but I would not really recommend using Barnyard2 right now because it has several issues in my opinion.  It goes crazy with CPU utilization after rules updates as it does a ton of SQL stuff in the database, it seems to randomly choke on stuff and just stop, and it has issues with referential integrity violations in the database when the references within Snort rules get reordered during updates. Bill

There's a known problem with netmap. Lots of folks are waiting for the update to drop to see if it solves the issue. Seel this thread: https://forum.pfsense.org/index.php?topic=108365.15

Great, thank you!!

sorry - been a while since I check on this thread. I was using Inline IPS mode via the em drives. I can try the legacy mode tonight.  thanks!

i have the same issue..upgrade to (3.2.9.1_14), now the snort unable to start.. please help!!

@ProgressCity: It Works! I guess I fiddled with the External List a bit too much. Bill, your explanations really gave insight into some misconceptions and misunderstandings I had about the way that things were parsed with snort rules and how alerts were "matched".    Thank you sincerely for your time and patience on all of this.  I greatly appreciate your efforts! Glad you got it working.  Generally the content of the EXTERNAL_NET is literally "!HOME_NET", which means any IP address not in HOME_NET is considered to be in EXTERNAL_NET.  In your case, EXTERNAL_NET contained only a single specific IP address; and that one happened to be just the link local IPv6 address.  So basically that rule should almost never match and fire (because the destination would never match your EXTERNAL_NET setting). A typical Snort setup has HOME_NET set to all the local firewalled networks, and EXTERNAL_NET is set literally to !HOME_NET.  The idea is that HOME_NET contains the networks being protected, and EXTERNAL_NET represents the home of the bad guys (which is considered to be everything not in HOME_NET).  HOME_NET and EXTERNAL_NET represent "source" and "destination" hosts or networks in the rules.  For a given rule, HOME_NET might be the "source" or it might be the "destination" of the traffic the rule is checking.  Only when everything matches will the rule fire.  This includes the direction of the flow, the source and destination networks, the ports (if defined), and the content of the traffic. So in the rule below, you need traffic containing the "content" given in the rule to be flowing from a host whose IP address is within HOME_NET from any source port to a host in EXTERNAL_NET with a destination port of 3478 in order for the rule to fire.  If anything does not match, the rule does not fire. alert udp $HOME_NET any -> $EXTERNAL_NET 3478 (msg:"ET INFO Session Traversal Utilities for NAT (STUN Binding Request)"; content:"|00 01|"; depth:2; content:"|21 12 a4 42|"; distance:2; within:4; reference:url,tools.ietf.org/html/rfc5389; classtype:attempted-user; sid:2016149; rev:2;) Bill

Not sure what happened, but tried restarting the service again a third time and it says that it is running now. snort Snort IDS/IPS Daemon Running

Here is a great thread of Suppress List contributions from some other Snort users:  https://forum.pfsense.org/index.php?topic=56267.0.  This is just my personal opinion – there are lots of issues with the preprocessor rules in Snort.  They seem to alert on a bunch of stuff that is somewhat common on the web today.  There was a lively discussion about two years ago here on the forum about this and other VRT and ET rules that are really obsolete but were never removed from the rules.  These at best consume CPU resources, and at worst can false-positive. Bill

My Snort VRT rules just updated.  No more MD5 issues.

same error for me also Starting rules update…  Time: 2016-07-12 11:06:35 Downloading Snort VRT rules md5 file snortrules-snapshot-2983.tar.gz.md5... Snort VRT rules md5 download failed. Server returned error code 403. Server error message was: 403 Forbidden Snort VRT rules will not be updated. Downloading Snort OpenAppID detectors md5 file snort-openappid.tar.gz.md5... Snort OpenAppID detectors md5 download failed. Server returned error code 403. Server error message was: 403 Forbidden Snort OpenAppID detectors will not be updated. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Snort GPLv2 Community Rules md5 download failed. Server returned error code 403. Server error message was: 403 Forbidden Snort GPLv2 Community Rules will not be updated. Downloading Emerging Threats Open rules md5 file emerging.rules.tar.gz.md5... Checking Emerging Threats Open rules md5 file... There is a new set of Emerging Threats Open rules posted. Downloading file 'emerging.rules.tar.gz'... Done downloading rules file. Extracting and installing Emerging Threats Open rules... Installation of Emerging Threats Open rules completed. Copying new config and map files... Updating rules configuration for: WAN ... Updating rules configuration for: LAN ... Restarting Snort to activate the new set of rules... Snort has restarted with your new set of rules. The Rules update has finished.  Time: 2016-07-12 11:07:08 snort security 3.2.9.1_14

@battles: Thanks.  I was trying to individually suppress a rule for my isp address in Services / Snort / Alerts, and upon clicking the + button, I got this error: The following input errors were detected: Suppress List 'wansuppress_57828044c1f52' is defined for this interface, but it could not be found! Wonder what this is about? Maybe a previously created/assigned suppress list that was later deleted.  Go to the INTERFACE SETTINGS tab for the Snort interface and set the SUPPRESS LIST to "default" and save the change.  Now go back to the ALERTS tab and try the suppress action again.  When you click the suppress icon on the ALERTS tab, it will auto-create a Suppress List file for the interface and assign it if one does not already exist.  If one is defined in the config.xml, then it will use that one instead.  In your case, one was defined in the config.xml for the interface but the actual content was not in the config.xml file.  This usually means the old list was deleted. Bill

Looks like snort 3.2.9.1_14 just became available which contains snort-2.9.8.3.  I was able to download my Snort VRT rules and start Snort.

Thanks a lot for your advice. So I send an e-mail to Voleatech, Germany, they said that the update is not in the official update catalogue yet, and promised to look the issue. Very soon I got an another email that the issue will be resolved soon. And now the latest package is available, and I just upgraded. Everything is working well now. Many thanks!

Thank you.  If possible, that would be great to add in the next update.

@Tantamount: @Wisiwyg: Thank you Bill. I just took a quick look at freshports - no update as of this post. Looks like koobs@freebsd.org is the maintainer. Hopefully s/he will have a chance to look it over soon. I emailed koobs back on the 5th  (nice fellow) and he said that after some more QA it'll be committed shortly. He mentioned this patch if one didn't want to wait – looks like there's been some activity since his email.  Apparently it's not as simple as compiling from source into a package: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210490 Yeah, there are some other fixes required to integrate Hyperscan into Suricata on FreeBSD.  The FreeBSD maintainer will get it worked out.  I will keep an eye on the progress and start working on the pfSense Suricata package as soon as FreeBSD ports is updated.  I also have to be sure the special patch we apply on pfSense for the legacy mode blocking works on the new version, so that adds a little extra time to the cycle. Bill

@joelesler: Hi.  Joel Esler here, I work for Talos (was VRT) and and the Program Manager for the ruleset.  (Note: I don't hang out in these forums all the time, so if I miss your reply, I'm sorry. That being said.  It's impossible for us to track the 1,000s of platforms that Snort is built into.  We tried, and we just couldn't keep it up.  We established the EOL policy, probably close to 13 years ago now…  and we've stuck by it. Its great to have your support in this forum. Bill Meeks the Dev/Maintainer of the Snort package has been doing a phenomenal job on what little free time he has available :) We're all just thrilled that out of the 1000's of platforms that use Snort, that you registed for an account here… It is this ( 1 of a 1000 ), that we here; really care about hehe…. Keep of the great work, and we're looking forward to 3.0 ...

What file specifically are you looking at on the LOGS tab?  Only the file named alert will be used by the ALERTS tab.  If you are looking at older history alert logs (those will have a timestamp in their name), then that data will not be displayed on the ALERTS tab.  It may simply be your box rotated the alert log when it reached the rotate size limit and no new alerts have come in since then. The above is just a guess, though.  Reply back with the exact log file name you are looking at where you see alerts. Bill