I suspect it is working now.  That bug with the number of entries to display on the BLOCKS tab would cause it to by default display just one row.  Forcibly saving a new numerical value would fix any bogus value that might have gotten saved when the bug was in the code. All these things are fallout from the Bootstrap conversion of the package.  Bootstrap implements things a bit differently than the old system, and lots of things related to form input elements had to be changed in the GUI code. Bill

Firewall rules have nothing at all to do with your Snort rules update problem.  It is complaining about the certificate trust chain.  There either is, or your configuration makes cURL think there is, a self-signed certificate in the chain. Have you tried removing Squid entirely for a test to see if the rules download then?  The Snort code uses the built-in system function cURL() to download updates.  That function is called with a parameter set to verify SSL peers (in other words, check the certification trust chain).  That check is failing on your system because of the some specific configuration you have.  My bet is the problem is with Squid. Bill

@ntct: Maybe similar problems about netmap. https://github.com/luigirizzo/netmap/issues/156 https://github.com/luigirizzo/netmap/issues/134 Hmm…might be some Netmap problems that are not directly related to Suricata.  pfSense 2.3 now compiles Netmap support into the kernel by default. Bill

There was a bug in the Suppress List code early on immediately after the initial Bootstrap version of the package was released.  It was eventually fixed, but it is possible it caused some junk to be left behind in your configuration. Bill

Good point and that is exactly what I was experiencing with Snort.  Seems to be working OK now after reinstall.  And just to follow up on my CRON issues that has cleared up as well. One of my CRON entries uses the wget command.  I'd forgotten I had to install that command as it is not native to the pFsense package.  So, for the machine I updated to 2.3 the wget command was already there and CRON worked.  For the machine I installed a fresh 2.3 the wget command was not there so CRON did not work and I assumed it was for some other reason.  Once I had time to look closer I realized the problem.  All is running smoothly now.  Again, thanks for your response.

@pfsenseboonie: Hi bmeeks, another one. When operating in legacy mode, blocks are shown on the blocks tab (https://<url>/suricata/suricata_blocked.php). Say I have list of blocks on this tab #1 - #7, If i want to delete block #3 and do so then blocks #3 - #7 are deleted instead of only #3</url> I will check this out.  I have some other fixes to put into the Suricata package as well. Bill

i have that rule in my supress List suppress gen_id 137, sig_id 1

Seems this issue resolved itself when I updated to the 3.2.9.1_11 package so I'm marking it at solved.

@nfr: This is now fixed since 3.2.9.1_11. I also had some old information in the configuration from years ago when when using squid proxy. I removed a bunch of lines that were related to that and did a restore configuration from file. When the system rebooted everything came up correctly as well as upgrading to 3.2.9.1_11 from 3.2.9.1_10. On a unrelated item I noticed that the <blockoffendersip>both</blockoffendersip> setting got cleared when comparing configuration files. I was able to change this back in the web interface and it created a <blockoffendersip>2</blockoffendersip> . Whoa.  The <blockoffiendersip>setting is not correct.  It should be "both".  Looks like another Bootstrap conversion boo-boo due to how combo select boxes are coded in Bootstrap.  That might explain what some other folks are seeing.  I will investigate the code to be sure.  In the meantime, that value in your config.xml really should be the string "both". UPDATE:  I found the source of that incorrect setting. The fix will be out soon. Thanks for reporting this to me. Bill</blockoffiendersip>

@jbhowlesr: Would you mind if I hit you up on a side bar private message? I have a few questions about some of the setting in Snort. Basically, I want to understand a little better what they are for and what they mean. I replied to your PM. Bill

I finally got it working  ;D ;D ;D As I have read in another posting, someone succeeded in deactivating all rules, started suricata, then activated the rules and restarted suricata again. Up from that point, suricata started showing alerts at least. Afterwards I let suricata rebuild the "Interface SID Management File Assignments", that´s when suricata started blocking packages and showing them red in the alerts view. So maybe there had been some incompatible rules or settings in the older pfs-version-data I imported in 2.3. Everything seems to be fine now. Thanks for your help.

You rock Bill. Thank you!

@bmeeks: The fix for this is waiting for the pfSense developers to approve and merge.  I posted it late last Friday afternoon, so they are probably taking a bit of well-deserved downtime over the weekend.  I expect them to merge the fix this week. Bill No problem. I did spend some time looking to see if this was already mentioned. I guess I overlooked it. Thank you however for this fix and all the work you do for Surricata on pfSense.

I already change to AC-BNFA still having the IP to Block source problem, the only way is to use both or destination. many thanks for the help

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.