OK I connected a tunnel from another pfSense box using 2.2.1-RELEASE and another using version 2.0.1-RELEASE ….I get the same result. I can ping from other computers on the remote LAN subnet to computers on the local LAN subnet but not from the pfSense boxes themselves. This should be an IPsec topic not a IDS/IPS topic.  I will start a new thread in the IPsec fourm.

@jeffh: In addition to what Bill said, what I do is run Snort on both WAN and LAN interfaces. On the LAN interface I have blocking disabled and quite a few rules enabled so I can get some visibility into what is happening on my network. On the WAN interface I have blocking enabled and only specific security related rules enabled. All rules that are running on the WAN (in blocking mode) are also running on the LAN (in alert mode). This allows me to block security threats, while still seeing what NAT'd local devices are having their traffic blocked, as well as alert on other rules that may not be security threats or that may have higher rates of false positives. This is the exact same thing that I do and it works great.  It does take a bit more memory and processing power, and a lot more if you're doing barnyard.  I ended up turning the barnyard push notifications off because of this…but with this combination, you get the blocking on the WAN and can then trace it to your internal LAN ip address.

I thought the same as I did find a reference to that while searching the forum. I changed the Web protocol to HTTP but that didn't help… I am not sure what it is.. I have 3 W8.1 machines that do the same thing. If I get some time I'll dig a little deeper. Yes I am very glad and thanks again for your help ...

Thank you for this feedback.  There are some other posts in the Package forum where the advice for Nano users is to bump up the size of /tmp (and possibly /var) because the default partition sizes are too small to download and unzip the ever larger rules tarballs.  Unfortunately, today there is no mechanism within the pfSense Package Manager system for a package to specify prerequisites that must be satisfied in order for the package to be eligible for installation.  Some example parameters that would be useful are installed RAM and free disk space on critical partitions. As a general statement, Snort or Suricata on a NanoBSD install will require a lot of careful attention and quite possibly some customizations such as you describe of increasing the default partition size for /tmp and also /var. Bill

I think it was blocking itself, actually.  Fixed.

set for SRC only @duck - where is the setting you are referring to, I see many preproc's since the upgrade when there was only 1

Yes, if you put Snort or Suricata on the WAN interface of your main office, then the package would see all traffic.  However, if you use NAT, the usefulness of the IDS is diminished a bit in that the only IP addresses you would ever see in the alerts will be those for the far-end Internet host and the WAN IP of your main office firewall.  It would be difficult in that scenario to track which host on your private LANs might be infected with or the target of malware. If you instead run the IDS on the LAN interfaces, you would see the IP addresses before they were NAT-mangled.  With the site-to-site VPN scenario you linked, I don't if the LAN approach would work. Bill

@Evad: Bill, After a total reinstall of pfSense from scratch … Snort installed like above .. Failed first time and installed on second try but no GUI... Ran the 'Reinstall Snort's GUI components' to get the GUI. Created a LAN interface and then made a WAN  'Add new interface mapping based on this one' Now it works .... no errors so far..... Thanks.... Glad it's working for you now, but it should not have been that much trouble the install.  Something is up somewhere and I just need to find what it is. As for your failure to start error with this message: snort[9610]: FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_61288_em1/rules/snort.rules(904) Unknown rule option: 'stream_size That indicates a needed preprocessor was not enabled.  Most likely it was the Stream5 preprocessor.  Don't know why that would be.  It is enabled by default.  The particular rule containing that rule option is on line 904 (that's what the 904 represents) in the file /usr/pbi/snort-i386/etc/snort/snort_61288_em1/rules/snort.rules.  Open that file in a text editor and go to line 904 to find the rule that generated the error. Bill

Verifying Googlebot https://support.google.com/webmasters/answer/80553?hl=en Google crawlers https://support.google.com/webmasters/answer/1061943?hl=en F.

There will be a description on the ALERTS tab for the alert generated by the IP address.  Post that alert description here.  If you are sure the alert is a false positive, you can either suppress that entire SID, or just suppress the SID when the IP matches the one in question. Post the actual alert description that is printed along with the blocked IP either on the ALERTS tab or the BLOCKS tab. Bill

You could probably double mod it: 10010 "content:" "content:!" 10010 "xxx" "yyy" But, depending on how many rules you have to mod, I would personnally make a custom rule for your needs and keep the original intact. Who knows, what if the original triggers one day?

I think the answer is not quite yet… I found this information in https://forum.pfsense.org/index.php?topic=86732.0 @gonzopancho: QuickAssist isn't supported in pfSense today, but we are actively working on a driver (with deep assist from Intel) to go back into the FreeBSD tree. I believe this is the last hoop to jump through before it is supported however, since according to this article it has been integrated in Snort since 2010 (Snort 2.9 Beta). http://www.securityweek.com/sourcefire-accelerates-snort-performance-intel-pattern-matching-technology-faster-detection [image: patience-yoda.jpg]

Glad you found it!  Just leave Snort running on the LAN interface.  When using NAT, it will be easier to identify problem LAN hosts when Snort is on the LAN and can see the real IP addresses before they are altered by the NAT engine. Bill

@jeffh: Thanks fsansfil, that looks good, but it looks like there might be one more column. Between the DPort and Class columns I have a column with large numbers. These numbers don't appear in the Alerts in the GUI, so I am having a hard time matching them up. Any help would be appreciated. That is the IP Header ID field. Bill

@fsansfil is spot on with his answer.  You will find all the files in the /var/log/snort tree.  In that tree there will be a subdirectory for each configured Snort interface.  The name will be a combination of a GUID and the physical interface name (for example, em0 is one if you have an older Intel NIC). Bill

@RayP: The old firewall didn't load, but didn't give the same error.  I re-downloaded the AMD image and tried to load again.  The previous error is gone, but now it's stopping at "Additional Files…" with a failed message.  Since it's a new problem I'll look for a new thread that is related. Thanks for the help. If it fails at the "additional files…" part, that would indicate some kind of problem downloading files from the package repository server. Bill

Oh…and one other small point.  Each time you update the Suricata package (or it gets reinstalled as part of a pfSense update), you will need to repeat the hand-edit of that /usr/local/pkg/suricata/suricata_yaml_template.inc file because it will be overwritten when Suricata is reinstalled. Bill

Never mind… looks like it might've been something else... From the system log... Mar 28 14:48:45 php-fpm[44942]: /pkg_mgr_install.php: XML_RPC_Client: Connection to RPC server packages.pfsense.org:443 failed. Operation timed out 103 Mar 28 14:48:45 php-fpm[44942]: /pkg_mgr_install.php: XMLRPC communication error: Operation timed out Another attempt a bit later worked just fine.

@jeffh: That worked perfectly, thanks! Glad it worked.  I added that feature a few revisions back, but it has not gotten a lot of use yet so far as I can tell.  It offers an easy way to manage rules using various lines in the enablesid.conf, disablesid.conf and modifysid.conf files.  It can work with just SID values, or you can also use regular expression matching.  This functionality was ported over from the Oinkmaster and PulledPork utilities. Bill