This will be fixed in the next Snort update, which should be out soon.  Just finished fixing a list of Suricata issues, so now my slate is clean and ready for me to tackle the reported Snort bugs. Sorry for all the little issues, but the conversion to Bootstrap for pfSense 2.3 was a big chore and lots of little errors crept in. Bill

Darn it!  I thought I had the Stream Memory Cap default set large enough, but apparently not true in all situations. Bill

@Creep89: I experience the same problem on my upgraded 2.3 (2.2.6 -> 2.3). Snort blocks all the IPs, but only one IP is shown under the Blocked tab. But if you download the blocked IP list, you can actually see that far more IPs are blocked. edit: Nevermind, setting a new value of blocked entries to view and hitting "save" actually resolves the issue, now all blocked IPs are shown. Ah-ha!  Thanks for posting the solution.  This is an artifact of some Bootstrap fixes.  That value is not being initialized properly.  I will take care of it in the next Snort package update.  I am working on Suricata now, but hope to finish it up today. Bill

Google doesn't trust their own internal networks so why should anybody else? It is normal that Google is 24/7 online and a good basis for the scripts called bots (robots) and from there scans will be a long not able to get rid of them. So many "peoples" are placing then there bots into Google or other 24/7 sites. If you will be scanned ones more it is not unusual so if nothing is opened at the WAN interface you can be forget that scans.

@bmeeks: @Soonie: You have two running, and one of them is probably a sort of "zombie".  Kill them all and then restart Snort.  This happens now and then for some unknown reason.  Multiple instances get started on the same interface.  I have never been able to pin down the cause. The two lines showing /usr/local/bin/snort -R 45659 are the duplicate instances on the same interface. Bill Oke ThX very much i kill the zombie ;-)

You can use the features on the SID MGMT tab to help automate "turning on" many of the GPLv2 rules.  Go to that tab, enable SID MGMT, then read through the comments in the sample enablesid.conf file.  Click the edit icon beside the file to open it for viewing.  It has comments to show you how to use the feature.  Should you decide to use the feature, create your own enableside.conf file and name it something besides "sample".  That's because those sample files are overwritten on each package reinstall, so if you make changes to the sample files they will get lost on the next update. Bill

Hi, that works. Thanks.

Thanks

Thanks Bill.  No NAT in the switch.  I will take another look after my 2.3 upgrade.

Snort and Suricata are way too memory hungry to run on a system with only 256 MB RAM and no swap.

It will vary by location (LAN vs WAN) of the IDS sensor.  Snort and Suricata both see packets from the WAN before they hit the packet filter, so no port translation has yet taken place on inbound (from Internet to your firewall) traffic.  When on the LAN, the IDS is seeing stuff after NAT translation to local addresses/ports. So think of a series circuit on the WAN side.  You have your NIC, then the IDS, and then the firewall.  So the IDS sees traffic before the firewall does and thus no firewall rules have been evaulated (to say block stuff) and NAT has not yet happened.  This is why the IDS will still alert even for inbound traffic the firewall will later block due to a rule. Now to get even more technical, Snort (and Suricata when running in the legacy mode) actually use libpcap to get a copy of the packets coming through the circuit from NIC to packet filter.  The IDS operates on this copy while the actual original packet continues through.  If the IDS decides the traffic is malicious, it inserts the offending IP address into the packet filter (firewall) and then kills any states that may have been established when that original packet went on through while the IDS was evaluating the copy. Bill

I will look into this one.  There were lots of changes in the ALERTS tab code for the Bootstrap and inline IPS updates.  Looks like something got messed up with the intermixing of HTML and PHP code. Bill

A new package version has been posted that fixed this issue.  It is package version 3.0_5. Bill

@vbentley: Hopefully, in response to CVE-2016-1345 https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160330-fp it will get bumped to 2.9.8.2 Snort on pfSense is NOT compiled with the "–enable-file-inspect" flag, so it should not be vulnerable according to the security bulletin. Updates to the pfSense binaries for Snort and Suricata only happen after those updates are posted in FreeBSD ports. Bill

I don't use any commercially provided VPN's so I'm not entirely certain where your problem is. However, perhaps terminating your side of the VPN on a new pfSense interface (LAN2/OPT1 whatever) introducing an additional hop may help if you want specific Snort rules (or none) for this interface only.