Thanks. I go check.

Suricata and Snort both depend on the values of the HOME_NET and EXTERNAL_NET variables being set correctly.  Many of the rules from both the VRT and Emerging Threats uses HOME_NET and EXTERNAL_NET as source and destination values for IP addresses. If the IP addresses in HOME_NET and EXTERNAL_NET are not correct, many rules will fail to trigger and fire alerts because all of the "conditions" for triggering are not met.  So first question would be have you modified any of the defaults for HOME_NET or EXTERNAL_NET?  If you are trying to monitor a VPN, it could be the IP addresses of the VPN tunnel are not getting properly placed in HOME_NET.  In that case, you would need to create a Pass List and use it as a customized HOME_NET. Bill

@afagund: Should I message the developers mail list? For me its clear we have a bug on this package. You can, but if you mention "_package on pfSens_e" or "pfSense" anywhere in your report they will just send you right back here as they will assume somehow pfSense is to blame.  The Snort package on pfSense uses the same Snort binary as is used on any other Linux/FreeBSD machine.  So just tell them you think you have a memory leak issue with Snort using the HTTP_INSPECT preprocessor with gzip encoding enabled and don't mention the platform you are running on unless they ask.  If they ask, just say "FreeBSD 11" and don't mention pfSense. I'm not trying to be coy and hide information, but just pointing out that the default response will likely be to send you right back to the pfSense forums if you mention pfSense in your bug report.  Your issue is not with the pfSense package per se, it is potentially with the Snort binary, and that binary is the same as any other FreeBSD user would be using without pfSense in the mix. Bill

Oh good grief, I didn't realize there was already custom rules section.  Nothing like reinventing the wheel.  :-[  Thanks Bill

@bmeeks: A better and more secure way to handle this type of issue is to identify which rule SID (Signature ID) is causing the block and either disable that rule entirely or suppress that alert for the impacted IP (your cloud provider's address or address space).  To identify the rule causing the block, look on the ALERTS tab for the interface and filter for the blocked IP.  See which rule SID (or it may be more than one) is causing the block.  You can suppress the alert by adding the rule SID to a suppress list that filters on source or destination IP, or you can click the "X" icon under the GID:SID column to disable that rule completely. Bill Thanks for the direction Bill.  I did exactly as you said and found the rule causing the error.  I've since suppressed it and am no longer running into issues.

Hi DaReaLDeviL, Bill Meeks has a good explanation of what Inline Mode is and its benefits over Legacy Mode here:   https://forum.pfsense.org/index.php?topic=108010.0 The biggest issue with inline mode is hardware compatibility and stability.  When running as a physical machine FreeBSD's netmap only supports a limited number of NIC chipsets.  Supported list of adapters: https://www.unix.com/man-page/freebsd/4/netmap/ But as for running it in a virtualized environment I'm not sure if pfSense's netmap supports vmware adapters.  Maybe someone has already tested and can chime in on this.  If it is supported I would think it would require you to configure SR-IOV (which your NIC does support) on your VMware Host.  If you're not in a production environment I'd say snapshot and see if it works.  Hope that helps.

Hey Sorry for the (very) late reply, stopped checking the thread. I have not resolved the issue, it still works in this counter intuitive manner. As of right now I am just letting it work with the rules suppressed and disabled. We have been working on moving to Suricata inline as a replacement, but haven't moved it from the testing stage yet. I've actually been away from the office for some time now and have to catch up on suricata dev. They were having issues with the inline mode and vlan tags. Hopefully that has been resolved.

What kind of hardware are you running?  What is the type and speed of the CPU and how much RAM? Suricata needs CPU, and the higher the packet load the more CPU it needs to keep up.  Granted with no rules enabled it should not need nearly as much, though.  Might be an issue with your NIC drivers and the Netmap module in FreeBSD.  As as been said in this forum about a thousand times, inline IPS mode uses the experimental Netmap kernel interface.  Some NICs don't work with Netmap at all, and others work in a buggy fashion.  Your NICs might be one of the latter. Put Suricata in Legacy Blocking Mode and see what the throughput is then.  This will isolate the problem down and hopefully show Netmap compatibility as the culprit. Bill

In Snort a Pass List entry should not prevent receiving an alert.  It just prevents that alert from going on to generate a block.  So you should still see alerts on the ALERTS tab.  The pass list is checked by the custom blocking plugin after it receives the alert but before it sends the IP address to the snort2c table.  If the alert's IP address is in the pass list, then the IP is not sent to the snort2c table but it should still show up on the ALERTS tab as an alert. Bill

Dale thanks for the suggestions.  After some time of testing I found: 1.  The primary problem was Snort's Preproc http was blocking most of the IP's for the speedtest, even after turning virtually all rules off.  If I would clear the blocks it would start to work again (instead of rebooting which also clears the blocks) before blocking all the IP's again.  I could not find a way to fix this except to turn off the Preproc http (which numerous posts claim will break much of Snort), or to install suppress rules to suppress the rules that were too aggressive (I didn't test the suppress method, find that too be a little cumbersome for basic functionality). 2.  The secondary problem with the upload speed being low was using the bce network driver (built in Broadcom NICs).  Apparently this driver or hardware has issues with BSD.  I switched to another NIC that used the bxe driver and the upload speed problem went away.  I'm going to try some better Intel NICs later to try and take advantage of the "Netmap" functionality. I'm testing Suricata now, finding it less cumbersome so far.

Okay, I read through the entire thread…one doesn't need to implement all those scripts as one can use the custom DNSBL Feed rules into PFBlockng...really grateful to BBcan177. I also changed firewall flowing rule to block with the quick set checked, interface: WAN, direction: any, family address: IPv4+IPv6,  protocol: TCP, source: any, destination: any, destination port range: other, then from the WebGUI to the WebGUI. I also added a second firewall flowing rule to block with the quick set checked, interface: WAN, direction: in, family address: IPv4+IPv6, protocol: TCP, source: any, destination: any, destination port range: other, then from outgoing privilege ports to outgoing privilege ports. Extremely grateful to jflsakfja as well thank you and wish you all the best.

@BMEEKS You are amazing THANK YOU!!!!

Well if you decide to test again with Snort let us know! Perhaps you were just running multiple interfaces and configured barnyard on the wrong one?

@necs-gungaro: Hello All I am suddenly have Failed Snort VRT downloads . Looks like the MD5 checksum has an error. So how do I clean that issue up so I get my VRT rules to download? I am using a Lanner router with pfSense 2.2.4 Thank You for any help in advance. What version of the Snort package are you running?  That is quite an old version of pfSense.  If you have not updated Snort since you installed that pfSense version, then the VRT rules for your Snort version may have been discontinued (depends on exactly which Snort version you have).  Snort rules are tied to specific binary versions and the VRT does continually roll older versions of rules out of support as they roll in newer versions. Bill

+1. I too encountered the "manual remove" messages and I never touched the automated installation. I do not recall whether I had the fatal error. Snort seems to work just fine but I may follow the instruction to remove and reinstall for good measure.

Hi, I found I have the same problem. I wasn't sure but today internet suddenly stopped when I was online and I found PPPoE is down because WAN IP changed. What happened is: Snort detected new IP connected to website IP I was browsing 5 minutes ago as "port sweep"  and effectively blocked my new WAN IP together with all internet taking down VoiP and Internet radio tuner. I like to know how to mitigate such problem correctly because next time it can be other false positive or rule trigger same outage. Is any rule can be added to whitelist WAN IP as alias? Thanks

@GemeenAapje: Hi guys I'm trying to configure snort to add some additional security to be web server. At the moment I'm running it and monitoring the alerts without blocking. My web server is within my home network and I'm running snort on pfSense router on the WAN interface only. Is this correct practice? One thing i see, for example, is when I'm using Deezer that I see my own external IP flag up as accessing iTunes, for example "ET POLICY iTunes User Agent" Before I enable blocking, I really want to be 2000% sure that my own IP is never going to be added to the banned list, blocking my web server from accessing the outside world. Any advice greatly welcome. Thanks Matt For home users I recommend running Snort on the LAN.  This lets you see actual LAN host IP addresses in the alerts.  If you run Snort on the WAN, then you can't see local LAN host IP addresses in any alerts.  Instead, all local host IP addresses will be the WAN IP of the firewall.  This is because Snort on the WAN sees inbound traffic from the web before the NAT rules are applied, so the destination IP for inbound Internet traffic is the external IP of the firewall.  When you run Snort on the LAN, it sees traffic after NAT has been removed, so the actual internal IP addresses of LAN hosts appear in the alerts. Snort has built-in safeguards that prevent the actual IP interface addresses on the firewall from being blocked.  If you get alerts from rules that you know are OK in your environment (such as that ET POLICY rule in your example), then you can disable those rules.  Be careful just enabling all the rule categories!  You will get a lot of noise.  For example, that ET POLICY rule set is mainly there for corporate network admins where corporate IT policies are in place that may forbid employees from accessing iTunes at work.  The admins would want an alert if an employee was attempting to access iTunes.  For a home user, this policy rule is likely not useful unless you really hate Apple and use only Google Play  :D. Bill

@pffan: Thanks for the response. I am testing from inside the LAN but I figured that because IIS bound traffic is exiting the LAN interface, it is subject to fw rules and thus snort inspection.  Also the preprocessor rules are generating alerts okay. The external net variable has been customized.  Not sure where the ipv6 address came from but the others are ips of my pfsense interfaces. I think the problem might be due to my custom pass list which I tried to make empty.  The local interface addresses are added automatically.  Can you confirm if traffic originating from an ip in the pass list is still checked?  Or is it just discarded immediately?  I think that might be the problem. One other thing I didn't mention is that haproxy is adding x-forward-for headers to http traffic and I was hoping to detect and block those addresses when offensive.  Is that possible or am I going about this the wrong way? A pass list entry prevents that IP address from being blocked, but it has no impact on the alert showing up on the ALERTS tab.  So the pass list has no bearing on what alerts you see.  It only determines whether or not the IP itself gets added to the "blocked IPs" snort2c table in the pf firewall. In your case, a failure to see alerts would be due to one or both of the following:  (1) the traffic in question is not actually traversing the firewall, or (2) the IP addressess in HOME_NET and EXTERNAL_NET are not correct in terms of the rule's logic, and thus the rule is not triggered. Bill

@bmeeks: You can turn if off, but if any of your enabled rules use keywords or rule options specific to the SIP preprocessor, then you will get errors when Snort starts up and it will not start successfully.  I would suggest simply disabling the rues generating the "noise" and leave the default preprocessor set enabled. Yes, that's what I meant: disable the individual rules, not the whole rule set. Thanks.