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

Never enable Snort blocking without first running for at least a week or two and reviewing what it's triggering and disabling signatures as appropriate, as the default Snort ruleset is way too touchy to be blocking.

At the moment nothing like that is in the code, but I guess it could be added.  Perhaps as an option that is configurable on the GLOBAL SETTINGS tab.  The line of code you altered to trust self-signed CAs was added to the Snort GUI code base a while back in an attempt to improve security, but it has the unintended side effect of interfering with some edge-case setups. Bill

Bill: Thanks for the update. I know it's complex to work on all the moving parts, Regards, Howard

@zxvv  Thanks very much for adding the ignore_scanned option.  I'm probably being slow, but I'm having trouble getting it to do what I need.  When I try to add an entry into ignore_scanned in the GUI, Snort fails to start.  I'm sure I'm not getting the syntax quite right. Basically, my set up and what I want to do are as follows: 1)  I have a WAN interface which gets a dynamic IP from my ISP.  Let's call that 12.34.56.78 2)  I have a NAT forward set up for a UDP port (let's say 1234) that forwards that port to a LAN address.  Let's call that 192.168.1.2 3)  When I connect using the service on UDP port 1234, the port scan preprocessor detects it as a port scanning attempt and blocks the incoming IP.  The portscanning engine is set only to look at UDP traffic. If it helps, that UDP port 1234 is the only UDP port that's fowarded. 4)  What I want to do is add an entry to ignore_scanned so that it ignores all traffic on UDP 1234 when deciding if it's being scanned. What do I type into the ignore_scanned box to achieve this please? I've tried various combinations of $HOME_NET, $EXTERNAL_NET, 192.168.1.2, 0.0.0.0/0 specifying port 1234 etc (the last entry just trying to catch any address)  but it's either ineffective or Snort doesn't start at all with the following error: FATAL ERROR: /usr/local/etc/snort/snort_57232_re0/snort.conf(355) => Invalid ip_list to 'ignore_scanned' option.