Bill, I just rebooted and Suricata is now running! [image: 1562524823426-screen-shot-2019-07-07-at-1.38.08-pm.png]

yups fixed this in next release to avoid extra space.

@asterix Could you share for us your last disablesid.conf ? maybe you have some NEWS. and that can use for snort and suricata ? or only suricata? Do you have any new post of config suricata for WAN and snort for LAN? Thanks for your help. Best Regards, Daniel T

You have multiple Suricata processes on the same interface. I count 5 on igb2. There should usually be only 1. Those multiple processes are chewing up your CPU. Are you by chance trying to run the Service Watchdog package with Suricata? If so, DON"T! It will cause this issue as it does not understand how Suricata works nor how to properly monitor it. If you don't have Service Watchdog, then something weird is happening on your box (unless you have a lot of VLANs on igb2). If you do have a lot of VLANs on that interface, I would suggest running on the parent only and not each VLAN. To kill those errant processes (assuming you don't have multiple Suricata-enabled VLANs on igb2), do this. Stop Suricata on whatever interface igb2 is (LAN, WAN or whatever). Look for any remaining Suricata processes using this command: ps -ax | grep suricata If you see any for interface igb2, then kill them with: kill -9 <pid> That should reduce your CPU utilization to almost nothing with no traffic.

@bmeeks said in (SOLVED) Suricata Interfaces have to be manually Restarted: @digdug3 said in (SOLVED) Suricata Interfaces have to be manually Restarted: @bmeeks Would it be possible to check for those processes during the uninstallation of the package? So you can warn the user? It tries to do that now, but does so by looking for a PID file in /var/run. A crashed/runaway process may no longer have a valid PID file in /var/run. I can look at some other approaches using pgrep maybe to find all suricata processes and then force kill them. Me with Suricata and Snort, and the former package maintainers before me for Snort, have been struggling with multiple instances getting launched forever. It stems somewhat from the way pfSense itself will sometimes issue multiple "restart all packages" commands in response to WAN IP changes or changes in the WAN interface state or problems with a gateway. These multiple "restart all packages" commands can lead to multiple instances of Suricata (or Snort) running on an interface. That sounds like a pain to deal with. It would be great if another approach could be implemented.

@wangel: Glad it's working for you. I was really pretty certain I had fixed the bug. I even went back through the binary code two more times to convince myself. All ways for that error to happen were removed from the code. So in your case, it seems you had what I call zombie Suricata processes out there, and your issues were actually coming from them as they would have been running old copies of the binary (hence the continuing error).

All fixed now, have DHCP running on each VLANs with proper FW rules! Thanks @NogBadTheBad !

This bug is corrected in the latest Suricata 4.1.4_4 package update. The release notes are here.

Perfect, thank you If you need any logs or anything from me, let me know Right now i have OPT1 and OPT2 as inline and LAN and Legacy Mode and it seems fine. Its likely to affect a fairly limited number of people right now so no rush on my side for this and i'm happy to trial anything you need Regards, Jamie

@jake said in Snort Package - Potential New Feature Teaser: They are all Intel I210-AT NICs. Would the PPPoE still be an issue if I'm running Inline mode only on the LAN side? I also had it Inline Mode on my VLAN interfaces, could that be an issue? Thanks for all your help. I'm happy to do any testing if needed. No, so long as the interface is not using PPPoE, the Intel i210-AT chip should be using the igb or perhaps the em driver. First you need to verify that by looking under STATUS > INTERFACES in the pfSense menu and finding your LAN interface. The type of driver will be shown in parentheses in the header band for each interface. If your LAN is not showing one of the compatible netmap driver families I posted earlier, then inline mode likely won't work for you. If you have one of the listed NIC driver families, then try altering the settings mentioned in this post: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces.

Ok, thanks for the reply. I asked it because now it rebuilds 4 interfaces every time... (before it was eight)

@bmeeks @Gertjan Thanks for the feedback. I deleted the log files (with Suricata disabled) and then restarted Suricata. The PHP errors have disappeared.

I usually suggest deleting the package and re-installing it, especially for major updates. This update is minor and changes only one PHP file, so you can just do a re-install on the PACKAGE MANAGER tab. If a delete and then install is recommended, I will always put a warning in the package release notes. Suricata will retain your settings even when you delete package unless you specifically uncheck the Save Settings on De-Install checkbox on the GLOBAL SETTINGS tab. That setting is enabled by default, so you don't lose any settings when you remove the package. So for this update, go to the PACKAGE MANAGER tab and click the re-install icon.

@kiokoman said in Suricata php errors: yeah i saw it wasn't fatal, and when i went to check that line i was pretty sure it was only a minor glich, I just thought it was right to advise, anyway thanks for the info Yes, thank you very much for the bug report. It was an easy fix on my end, but this is the weekend and I'm not sure the pfSense guy that handles FreeBSD ports is working. It may be Monday before my fix gets merged and appears as an updated package on the Installed Packages tab of PACKAGE MANAGER.

Thanks, that did get it working. Not sure what the install issue was but glad it's good now!

@Grunt0307 said in Suricata Log Interpretation: Makes sense, let me ask you this then. I intend to have a DMZ network setup on another interface. If I configured Suricata to inspect my LAN and DMZ interfaces, that will increase the load on the system, correct? I'm assuming it would launch an instance of Suricata for each monitored interface resulting in duplicate data being loaded for each interface. That is correct. Each monitored Suricata interface will be a separate instance, and so resource utilization will increase when monitoring multiple interfaces. You can manage this by limiting the rules applied to each interface to only those needed to protect the assets behind that interface. Refer to my earlier example about mail servers, public-facing DNS servers and so forth. But in the end there is no free lunch. Using a tool like an IPS with rules takes CPU resources. Fortune 500 corporations do this by throwing a lot of really big iron at the problem (servers with lots of RAM and multiple Xeon server CPUs). My first reply about not putting the IPS on the WAN was based on the assumption you had only a WAN and LAN. That's the most common configuration for pfSense users. Some may have a number of VLANs running on say the LAN interface. In that case you can have Suricata run in promiscuous mode to see all the traffic on the interface to help with resource conservation. Promiscuous mode doesn't help with separate physical interfaces, though. I would think that with configuring the NIC's sysctrl settings like those I linked to several replies back, and choosing wisely which rules to enable, that you can achieve very close to linespeed on the SG-5100. Making sure flow control is disabled on the NIC is said to make a big difference.