@bmeeks: Suricata does some internal house cleaning as it runs.  I suspect it is recovering some RAM that was initially allocated and then later not needed.  During startup a lot of stuff is happening all at once in terms of loading the rule set and parsing/decoding the text into all the internal structures used for the pattern matching algorithm. If you have 6 active interfaces all with a decent number of enabled rules, that would account for the 2 GB number.  Also, based on 6 interfaces with a lot of enabled rules on each, I guess the 10 GB number is not that bad for startup usage. So long as Suricata is actually still running on each interface, you are not "losing" any protection because of the RAM usage reduction.  Just verify all the interfaces show Suricata running over on the INTERFACES tab. Bill Awesome! Thanks very much for the info. That makes sense. Yes the service and each individual interface remains running. Thanks again!!

@Xentrk: Thanks for the reply Bill. You confirmed the path I need to take. After my post, I did more research and realized it will take time to tune and learn more about suricata. Thank you for the tip on the forum posting "Taming the Beast".  I will definitely visit that post. I gave google a workout with my searches on suricata but never did come across that thread. The reason I did not get impacted until now is I had suricata turned on the WAN interface. Yet, all of my browsing was done on the VPN inteface. My problems only started when testing web browsing over the native WAN interface. That is when the rules started impacting me.  I have some users in the family that want native WAN while the rest of us want VPN to USA 100 percent of the time. I am trying to reduce my router foot print and go 100 percent pfSense.  I think I have things stable now that suricata is turned off.  I noticed my disk space started growing.  For next steps, I plan to do some more reading on the pfSense forum and other resources to learn all I can about suricata before I start testing it again. Thanks again for the advice and help! For the disk space growing issue, make sure all the automatic Log Management functions are turned on the LOGS MGMT tab.  They will auto-rotate and delete logs based on values set on that tab.  You can adjust the limits to match the size of your disk.  Suricata can be a "chatty" logger. Bill

Installed last night so far zero issues thanks for getting this out

Thanks Bill, its working a treat now :) alert icmp any any -> any any (msg:"ICMP Packet found";sid:1000001;rev:1;classtype:icmp-event) [image: Untitled.png] [image: Untitled.png_thumb]

It's been a while since I've toyed with Barnyard2.  It definitely sounds like a permissions or path thing to me, though.  Remember the running Barnyard2 process will not have the same environment variables set as your shell account will have.  So things that "just work" at a CLI prompt many times will not work when executed from within a script or a daemon. Is your private key literally in /etc, or is it maybe actually in /usr/local/etc?  The latter is where I think it should generally be on FreeBSD and pfSense.  All of the Snort, Suricata and Barnyard2 stuff is in /usr/local/etc. Bill

@techbee: While pfsense dropped the Layer 7 filtering and suggested using Snort,  I don't know why other commercial firewall still have Layer 7 filtering on them. I forgot what commercial firewall was that, probably Sophos. I believe it was because the Layer 7 filtering in pfSense was never great and it was a little hard to maintain.  I think it was more an experiment from one of the developers who has since departed.  The OpenAppID system now in Snort was open-sourced by Sourcefire soon after acquiring Snort.  It is modeled after some of their older proprietary stuff.  You have the basic engine available in the Snort binary, but to complete the circle and make it actually do something you need custom AppID rules.  A third party provider volunteered to create and maintain a cache of OpenAppID rules for the Snort package on pfSense.  Those rules are hosted on a University web site in Brazil.  You can enable their download in the Snort GUI on the GLOBAL SETTINGS tab.  Be aware, though, that the hosting web site does geo-blocking on certain countries.  If you reside in one of the countries they geo-block, then you won't be able to download the rules (at least not without using a VPN to get around the geo-blocking). Bill

This is a question you should direct to the Snort mailing list.  I don't have the URL, but you should be able to quickly find it on Google.  I know there is one. Bill

@justsomeone: Snort wont start after updating some rules. I have un-installed and reinstalled. Any help would be much appreciated. Here are the logs:``` Time Process PID Message Jul 21 15:03:54 php-fpm 40562 /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 35291 -D -q --suppress-config-log -l /var/log/snort/snort_em035291 --pid-path /var/run --nolock-pidfile -G 35291 -c /usr/local/etc/snort/snort_35291_em0/snort.conf -i em0' returned exit code '1', the output was '' Jul 21 15:03:54 snort 48245 FATAL ERROR: /usr/local/etc/snort/snort_35291_em0/rules/snort.rules(4832) byte_test rule option cannot extract more than 4 bytes without valid string prefix. Jul 21 15:03:53 php-fpm 40562 /snort/snort_interfaces.php: [Snort] Snort START for WAN(em0)... Jul 21 15:03:53 php-fpm 40562 /snort/snort_interfaces.php: Starting Snort on WAN(em0) per user request... Jul 21 15:03:51 php-fpm 40562 /snort/snort_interfaces.php: [Snort] Building new sid-msg.map file for WAN... Jul 21 15:03:50 php-fpm 40562 /snort/snort_interfaces.php: [Snort] Enabling any flowbit-required rules for: WAN... Jul 21 15:03:42 php-fpm 40562 /snort/snort_interfaces.php: [Snort] Updating rules configuration for: WAN ... This error is caused by a mis-written rule signature.  Likely it was updated by the authors but the error was not caught before the rule was added to the update tar ball.  You can find the errant rule and disable it by "decoding" the error message. Here is the snippet of the error message you need: /usr/local/etc/snort/snort_35291_em0/rules/snort.rules(4832) This tells you the file containing the rules where the error happened.  The file is /usr/local/etc/snort/snort_35291_em0/rules/snort.rules, and the error is on line 4832 in that file.  So open the file in an editor, locate line 4832, examine the rule there to find the SID and category and then disable that rule in the GUI on the RULES tab. Bill

@crester: I don't know why but rebooting had worked. 99 times out of 100 this means you had duplicate Snort instances running on the same interface.  To the GUI, one of those process instances is like a zombie and lost.  So any changes made to HOMENET or anything else in the GUI don't get applied to that running zombie process.  Rebooting will kill everything and then you get back to a single Snort instance per configured interface and things are normal. Bill

The GUI package update to accompany the binary update has been posted for review and approval by the pfSense developer team.  Should get merged into the package repository soon.  Here is a link to the Pull Request with details on bug fixes and the new feature in this coming update. https://github.com/pfsense/FreeBSD-ports/pull/393 I will post a full set of release notes after the update is merged into the package repositories and is available for users to install. Bill

I realize this is an old topic - however, maybe someone out there has crossed this bridge and can shed some light on the issue. I am running into the same problem as the OP.  Suricata (Inline - Intel i211) effectively shuts down the WAN interface and runs the CPU up to 100%.  Nothing in the logs indicates a problem, suricata log just goes silent.  A stop / start of Suricata and all is well again. The few times I've encountered this it did not seem to happen during times of high load on the interfaces. OP - Did you have any luck in adjusting buffers?

MrGlasspoole…just to be clear I do not recommend you disable those rules. If you are not getting many alerts "Suppress" might be a better route for you, assuming you have the available resources for your firewall to work harder.

I run Snort on the VLANS and exclude the parent interface, the untagged VLAN on my settup id for LAN management.

And after F*****g with it for the last half hour I hit the start button in the GUI…...and it's running.......

Figured it out, I didn't have a description entered and it wasn't saving my work. Added a description to the alias and it's working now. Edit: Spoke too soon, still not working and it's still blocking that IP.  :(

Check the Package Manager and upgrade Snort, the issue will be gone

I have same issue when I update pfsense after rebooting he update couple of package and failed to update suricata. I have uninstall suricata and re-install it again and working fine now without lose any configuration.

I know this is a bit older, but this request doesnt pumped into any release for the httpd extend custom option, why?

Found them!  OpenAppID rules, I had them all enabled. Logs cleared and back to normal ::)