I managed to circumvent the issue by adding a check mark to the following option under the Snort LAN interface general setting: Stream Inserts Do not evaluate stream inserted packets against the detection engine Snort is now running but I find it interesting that the DNS alerts previously mentioned have stopped when using the LAN interface only. I've turned Snort on for both using all the categories and receive these types of entries again. I am guessing these are false positives due to the fact that clicking on the magnifying glass for some of the entries show that the IP resolves to ns1.google.com. 2017-02-08 23:18:10 1 UDP Attempted User Privilege Gain 216.239.32.10   53 192.168.0.5   50136 3:19187   PROTOCOL-DNS TMG Firewall Client long host entry exploit attempt IP address "216.239.32.10" resolves to host "ns1.google.com" I am still confused however why Snort LAN is not providing me these alerts as it must be an internal host being natted creating the false positives. Any input would be greatly appreciated. Cheers. E

update, working now. I uninstalled one more time.  Then manually deleted some of the snort scripts, files and directories.  On the subsequent reload, the package installed with no errors in the package and started correctly. However, these 3 rules failed to download.  I wait for results when regular downloads run as scheduled. Snort VRT Rules Snort GPLv2 Community Rules Snort OpenAppID Detectors

I can confirm that exact this issue still exists. Happened during update to 3.1.2_2 Suricata was disabled (not in menu) but still in package manger under "installed packages".  So only uninstall and new install worked!!

@huckabuck: This isn't totally on topic to the OP. My pf box has 6 igb int. I have an esx server downstream running security onion. I don't want to use Suricata for IPS but I do want to use netmap as a tap for all interfaces then send the whole stream to security onion on an unused int. Can Suricata be put in inline mode with IPS not blocking anything and use suricata.yml to configure the tap interfaces? Wouldn't this be easier to accomplish at the switch versus within the firewall?

Well, I've been playing with it for a while, and my first hurdle was getting pfSense to acknowledge/see traffic not actually destined for it on the monitor interface(s). Creating a bridge group seems to be the solution, but Snort needs to still monitor the actual interface(s), and not the bridge for it to work. My second hurdle is with Barnyard. The config page made it seem as though I could possibly nab packet captures/dumps right from the UI, which seems to be incorrect. So, that means pfSense is only usable as a sensor, which is fine. It's ability to disable/suppress Snort rules/alerts is way ahead of what the SO people are doing. So I've been working on getting Barnyard2 in pfSense to push the events into Security Onion's MySQL database. I found an older howto on the Spiceworks forum, but it seems to no longer be valid. Security Onion no longer uses Snorby and instead now uses Sguil. The next step is probably to ask the Security Onion people for help. Anyone have any insight?

Hello vbentley, thank's for your reply, but I was misunderstood! The very open WLAN has for sure no access to the LAN, only to WAN and LAN has no access to the WLAN, only to WAN. My question is different (maybe my english is not the best) :-[: I want to setup snort on LAN and WAN, but only for traffic to and from LAN. I'm searching on how to setup the rules for snort in a way, that WLAN and WAN for WLAN is generally not affected. This "Freifunk"-thing is based on a club and one of the rules in that association is not to sniff any traffic (gentlemen's agreement). That's my goal! Many thanks!

Thanks for the help..

How to find the link-local machine… https://forum.pfsense.org/index.php?topic=122888.msg688720#msg688720

Yes, I found the line but I'm still perplexed why I can't renice a process through cron. In openwrt, it was no problem.  Why is cron different here???

if they're blocks to normal google searches, let them pass. same with akamai blocks.

@genesislubrigas: PS:  I dont use pfsense captive portal You might want to fix the totally misleading subject, plus move this to some Linux forum.

The dependency is already fixed, no need to do anything here. https://github.com/pfsense/FreeBSD-ports/blob/devel/security/pfSense-pkg-suricata/Makefile#L16

@bmeeks: Hey Sorry for the late reply. I have rebuilt my VM lab on Vbox and tested on it, very good success with Suppression list but still can't figure out pass list. But for now that will do nicely, Thank you very much for your help Bill.

Great job Bill, well explained. I absolutely agree with you that the best Passlist option is "none" for Inline mode.

Maybe with ??? http://asecuritysite.com/forensics/snort?fname=webpage.pcap&rulesname=ruleip.rules IP address alert tcp any any <> any any (pcre:"/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/"; msg:"IP address";content:"number";nocase;sid:9000003;rev:1;)

@AR15USR: I currently have Snort configured and running but Im interested in checking out Suricata for a possible switch over. Can I install Suricata whilst already having Snort installed? Maybe just run Snort on the WAN and Suricata on the LAN for a testing period? Sure, but you can't run them both in blocking mode unless you operate Suricata using the new inline IPS mode.  That's because Snort and Suricata share the same pf firewall table for storing their blocked IP addresses, so if both packages are in blocking mode (with Suricata in Legacy mode blocking) they will clash over the pf table and not play well together. Inline IPS mode is only supported on a few network cards, though.  If the NIC in your firewall on the interface where you want to run Suricata is not on the supported list, switching on IPS mode in Suricata will break connectivity all the way up to possibly needing a firewall reboot to fix.  So be warned!  Check your NIC compatibility first.  Look for "netmap support".  Searching Google and the FreeBSD site will help you see if the NIC hardware and associated driver on your firewall support netmap (which is used by Suricata for inline IPS mode). I would just leave Snort as-is and install Suricata on the other interface in IDS mode.  Do not enable blocking.  You will be able to see all the alerts Suricata generates and from that determine how you like it as compared to Snort. Bill

@user12: Hey there! As soon as I active OpenAppID-Rules in my Snort configuration (downloading the rules is just working finde) the system will tell me: FATAL ERROR: /usr/local/etc/snort/snort_8522_rl0/rules/snort.rules(19371) Rule options must be enclosed in '(' and ')'. And the snort service won't start anymore… ideas? I just downloaded the rules and actived them for my interface. Snort is telling you what is wrong right here:  Rule options must be enclosed in '(' and ')'.  Snort will stop when it encounters any errors in a rule.  The snort.rules file is simply the collection of rules you have chosen from all the categories you have enabled.  To see exactly which rule it does not like, open that file and look on line #19371.  Snort prints the line number of the rule with the syntax error.  The error is caused by the rule writer and not the Snort package itself. See my reply this user's problem for more details:  https://forum.pfsense.org/index.php?topic=123883.msg686669#msg686669. You should also complain to the rule author (at the site where you are downloading the OpenAppID rules) to let him or her know the rule is defective.  I wish the Snort VRT developers would have Snort operate like Suricata and just log a syntax error, skip the bad rule, and go on to the next one instead of stopping with a Fatal Error as it does now.  Stopping with the fatal error leaves you totally unprotected, while skipping a rule or two would still leave you with some protection in place. Bill