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

Troubleshooting this one may be tricky given its sort of random nature. Suricata could be running out of memory, but it should log some kind of error before just stopping. It might be you have traffic triggering an obscure rule with a bug in it that causes a crash, but I would say that is unlikely because with all the people using Suricata and various rules you would expect others to have the same problem with the rule. It could be a hardware problem (most likely with a flaky memory chip) that manifests itself only during high resource utilization. When you say it runs for a "short period", just how long is that?  Seconds, minutes or maybe an hour or two? Which logs are you looking at for errors?  Suricata has its own log you can view on the LOGS tab.  Some info (although limited) will be in the pfSense system log. Bill

@jimp: Looks like the port update was only put into devel (pfSense 2.4) and RELENG_2_3 (pfSense 2.3.2) and not RELENG_2_3_1. Should be fixed up at some point today unless there's a reason it was kept out of there that I am not seeing. @jimp is correct.  Renato is working on getting the new package into RELENG_2_3_1 as well, but I think he had some other more pressing fires to fight earlier today.  He and I have swapped e-mails and he said he will get the update posted. Bill

Snort uses DAQ and libpcap as its data acquistion layer on the physical interfacd.  It puts the physical interface into promiscuous mode so that it see all traffic hitting the interface.  That's why Snort is seeing your PIA traffic without being explicitly configured for it. In terms of the available interfaces in the drop-down box on the Snort Interface configuration tab, it simply queries pfSense for all the configured interfaces and displays them.  Probably not the best implementation, but for now Snort just thinks any interface returned by the system is an actual physical one.  So it doesn't really understand that your PIA tunnel really runs on the WAN but should be treated as distinct. Bill

Thanks Bill!

My problems began about June 17th after my pfSense upgrade, which I believe is before any Snort EOL took place, correct? Thank you for keeping Snort up to date and providing support, Bill.  I'm not about to blame you for anything.  I just wish I could find a smoking gun in the logs to point me to a solution.  I'll try the next version of Snort when it comes out but I don't think it's a rules issue at this point.  I would be happy to be proven wrong, though. -Justin

Sorry guys … my fault for being late submitting the update pull request.  The Snort 2.9.8.3 update was a little late getting into the FreeBSD ports tree, and then I missed my own deadline posting the update for review by the pfSense team.  I did not get the update posted until very late this past Friday evening.  The updated package is posted to the DEVEL tree of pfSense and should be in the RELEASE tree in a day or two.  The Independence Day holiday weekend here in the U.S. is another contributor to the delay. Once the updated 3.2.9.1_14 package appears, then Snort will work again.  That update includes the new 2.9.8.3 Snort binary and will use the 2.9.8.3 rules.  Suricata will work with any VRT rules version, but the Snort binary is locked to only matching rules versions.  This is a decision made by the Snort developers. Bill

This will be fixed soon.  An updated package pull request has been posted and is waiting to be merged into the RELEASE pfSense package repository.  The updated package is already in the DEVEL tree. The July 4 holiday weekend here in the United States has slowed things down a little bit.  It was ultimately my mistake for letting the EOL date of the Snort VRT rules sneak up on me.  I was not timely in getting the 2.9.8.3 update for the Snort binary out there.  The rules for the 2.9.8.0 version that is currently in pfSense RELEASE went EOL on July 1. Bill

@AsgardianFW: Bill, Thanks for the reply.  I have dug deeper into the issue and I'd like your opinion.  I can narrow the problem down to 3 rules in emerging-dos: 1:2014384 - ET DOS Microsoft Remote Desktop (RDP) Syn then Reset 30 Second DoS Attempt 1:2014385 - ET DOS Microsoft Remote Desktop (RDP) Syn/Ack Outbound Flowbit Set 1:2014386 - ET DOS Microsoft Remote Desktop (RDP) Session Established Flowbit Set When I disable #2, then everything appears to be back to normal (i.e., I can make normal RDP connections with no delay). When I enable #2 but disable #1 and #3 then I can get RDP connections to work, but the connection process is very slow. If I enable #2 with either #1 or #3, then RDP connections fail again. So, I will certainly disable #2 for now.  But should I drop this issue until 3.1 finally makes it into pfSense (3.1 does seem to be in stable release mode, but not certain how long it takes to make it all the way into pfSense) or should I attempt to debug further what makes that rule so bad?  I guess it is Netmap related as I don't get this problem in "Legacy" mode. Thanks. Rather than spending a ton of time debugging, I would be tempted to wait for the next Suricata update to go RELEASE and get into the FreeBSD ports tree.  Once it is posted in ports, I can submit an update request to the pfSense team.  There are several Netmap fixes in the next Suricata release, but I don't know if this particular issue you have identified is one of them or not.  I have not closely followed all the back and forth with the issues and fixes on the Suricata redmine site. Bill

Yes, this is the plan when the next 3.x update hits FreeBSD ports. Bill

try snort_p2p work well for me

Configured as well as SNORT

Couple of other things to consider – 1. By default in the pfSense Snort package, the vast majority of the Community rules are disabled.  Simply checking on the category on the RULES tab is not enough.  You have to individually (or using the SELECT ALL option on the RULES tab) enable the vast majority of them. 2. If you are using a SPAN port on the switch, then the sensor sees all traffic the switch does when mirroring ports.  However, the Snort sensor will only see traffic that is specifically passing through the firewall.  Don't know the particulars of the alerts you are seeing on the monitor and not the pfSense instance, but is it possible that host-to-host traffic on the LAN side is what the sensor is alerting on when pfSense does not?  The pfSense sensor will only see traffic either outbound to or inbound from the Internet.  Traffic from one LAN host to another will be seen by the passive Snort sensor but not the pfSense Snort sensor. Bill

Well, I've temporarily fixed it by modestly increasing the /tmp partition to 96MiB, but I suspect I'll run into problems again soon. Slightly irritatingly, unticking System/Advanced/Misc/Use RAMdisks doesn't seem to work on this version of pfSense/nanoBSD, so I can't set it to a partition on the Flash disk. It's a shame this little box has only lasted just over a year on my home network, looks like I'll have to buy a bigger one, like a LinITX APU2 C4 4GB. At least that would have enough memory and grunt to cope for a while. Thanks for the pointers Bill. smoker