@dales: Maybe I misunderstood the initial question, but in addition to the info Bill provided, I think you will need to adjust the pass list.  The default list includes the LAN, so even with BOTH selected in the blocking setup, the LAN IP won't get added to snort2c. That is correct in regards to the default pass list.  I forgot to mention that it will default white list LAN hosts.  You can stop that behavior if you want by creating a custom pass list and assigning it to the interface.  The default pass list setup will stop LAN hosts from communicating with bad external hosts if DST is blocked, or it will keep bad hosts from talking to LAN hosts if SRC is blocked.  Using the default of BOTH is the best of both worlds, especially when using the default pass list where all LAN hosts are white listed. So with BOTH selected as "Which IP to block", a bad external host is flagged and blocked whether it is the source or destination of malicious traffic (as detected by Snort).  Now with the block in place, no other LAN host can communicate with that bad external host.  However, any LAN host can still talk out to any other external host. Bill

No worries, at least I can do, from time to time, to post when a new version is available. Please let us know, as you always do, in a release note, what will change(if something is customized further in pfSense), when the new version will be ready. Thank you for maintaining Suricata also.

Hi! Thanks for introducing me to the High Availability of Snort. I will look in to it, although I will not be able to do any coding for that, cause of the lack of expertise. The high availability would only be required in pfsense for systems which have a tightly limited failure gap (let it be downtime, lost packets or dropped connections). The community of the paid version (if such) is probably already looking in to this. Thanks again!

Mine updated fine. Try reinstalling the package.

You are almost certainly hitting a Netmap compatibility problem.  Could be the higher interrupt rates that come with higher traffic rates, but also could be other buffer-related problems.  Netmap on FreeBSD, and then Netmap on FreeBSD within Suricata, are both still maturing technologies.  Translated to plain English that means expect some bugs to still be present. I have tested Suricata inline mode with em0 virtual NICs on VMware Workstation VMs and it works, but I have not tried high traffic rates.  I don't really have a good way of simulating realistic loading in my simple home lab.  I have not tested Inline IPS Mode on ESXi virtual machines. Bill

I had this issue with pfSesne 2.4.2 and had no luck fixing the issue with any of the suggestions. Though I do think I have now found out why the WAN interface went down. As I had set up Snort previously, access to checkip.dyndns.org was noted in the Alerts tab. Enabling a suppression list for the following IP addresses seems to have corrected my connection issues. suppress gen_id 1, sig_id 2014932, track by_src, ip 91.198.22.70 suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.38.70 suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.43.70 suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.43.71

what type of alias are you using? seems like you use URL(IPs). try to add the ip to a host-type-alias or use a network-type-alias.

should be easy: in the snort settings you can create a passlist and assign a pfsense-alias to it. then you have to assign that passlist to the snort-settings of the interface. after that you have to restart snort on that interface.

You have an eight-core CPU, so as @ntct says, increase the Stream Memcap value on the FLOW/STREAM tab to at least 256 MB and try to start again.  Keep increasing the value in 4 MB or 8 MB chunks until Suricata starts.  You can then try backing it down if you wish until it breaks, then bump it up slightly.  Some changes in the Suricata binary in a recent revision caused an increase in needed stream memory when using high core-count CPUs.  The old default of 32 MB is too low. Bill

They did reply to my bug report that it was resolved as well. Was just able to test it today to confirm that it is indeed resolved. Thanks for the follow-up bmeeks

NogBadTheBad and ecfx thank you for your instant reply. The site of Emerging Threats is very useful.

No, Suricata on pfSense can't do that (block the X-Forwarded-For address). Bill

See this post, https://www.linkedin.com/pulse/qisniff-sniffs-quantum-injection-mayur-agnihotri, for details about the attack and the mention of the tool (qisniff).  Here is the link to the tool itself:  https://github.com/zond/qisniff Bill

@Preacher22: Is there a central location some place where these sorts of concepts are documented? Unfortunately not – at least I've never found one.  There is at least one thread here on the pfSense forum that contains suggestions from other experienced users on which rules can safely be either disabled or their alerts suppressed.  You will have to search for "suppress list", for example, in the IDS/IPS sub-forum. Bill

I posted to redmine. I will see what kind of answers I get.

Right, that's what I thought. If you use the pass list to create a 'sub-alias', that gets used in the Suricata Interface Inspect and Protect drop downs for Legacy and Inline.

I apologize, I didn't even notice the flaw. I have this anti-torrenting setup on my VPN interface, I want to allow torrenting on my WAN because I know the traffic inside my network and who's doing what, my dad and I are the main torrenters. However, I give VPNs out to friends who torrent and I'd rather have them off, just because I don't know what they're downloading.