@crept: As for it to not show up in the Alerts tab, could this be a wrong configuration on my end? Thank you Bill! No, it's an issue with the way the Suricata binary logs drops when using Netmap.  I probably need to change the way the GUI gets alerts and drops when using the Inline IPS mode (which uses Netmap).  This happens from time to time. Bill

I had the same issue. Turned out I had bad entry in the whitelist alias, forgot to put 0's for the Net address. Corrected it and problem went away.

@bbspace: Thank you for this reply, Bill. I thought this was the case; I couldn't figure out why I just didn't get it. I appreciate your work in maintaining the package. May I suggest a feature that would allow to PCRE through the rules folder and pick just the rules wanted would be nice. If I have the time maybe I'll try a submitting a PR after I delve deeper into the package source. Cheers! All of the code for the SID MGMT rule selection logic is in the file /usr/local/pkg/snort/snort.inc and the initial function in that file is snort_prepare_rule_files().  That main function calls a number of other functions to build the rule set using the SID MGMT configurations.  It is all commented fairly well.  The one big concern would be not to break any of the existing functionality, so lots of testing would be required to verify no unexpected behavior creeps in. Bill

UPDATE This problem turned out to be a typo in the updated MD5 filename on the Snort.org download site.  After some email communications with the Snort team the problem was corrected on their download site.  This issue should be resolved now. Bill

This problem should be fixed now.  I heard back from the Snort.org team and the typo in the MD5 filename has been corrected. Bill

I apologize about the lack of info it is below. As far as I can tell the updating is working (log below). pfSense: 2.4.3-RELEASE (amd64) built on Mon Mar 26 18:02:04 CDT 2018 FreeBSD 11.1-RELEASE-p7 snort:3.2.9.6_1 Manage Rule Set Log: Starting rules update…  Time: 2018-01-14 03:26:58 Downloading Snort VRT rules md5 file snortrules-snapshot-2990.tar.gz.md5... Checking Snort VRT rules md5 file... There is a new set of Snort VRT rules posted. Downloading file 'snortrules-snapshot-2990.tar.gz'... Done downloading rules file. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Checking Snort GPLv2 Community Rules md5 file... There is a new set of Snort GPLv2 Community Rules posted. Downloading file 'community-rules.tar.gz'... Done downloading rules file. Extracting and installing Snort VRT rules... Using Snort VRT precompiled SO rules for FreeBSD-10-0 ... Installation of Snort VRT rules completed. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Copying new config and map files... Updating rules configuration for: WAN ... The Rules update has finished.  Time: 2018-01-14 03:27:36 Starting rules update...  Time: 2018-05-02 07:56:00 Downloading Snort Subscriber rules md5 file snortrules-snapshot-2990.tar.gz.md5... Checking Snort Subscriber rules md5 file... There is a new set of Snort Subscriber rules posted. Downloading file 'snortrules-snapshot-2990.tar.gz'... Done downloading rules file. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Checking Snort GPLv2 Community Rules md5 file... There is a new set of Snort GPLv2 Community Rules posted. Downloading file 'community-rules.tar.gz'... Done downloading rules file. Extracting and installing Snort Subscriber Ruleset... Using Snort Subscriber precompiled SO rules for FreeBSD-10-0 ... Installation of Snort Subscriber rules completed. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Copying new config and map files... Updating rules configuration for: WAN ... The Rules update has finished.  Time: 2018-05-02 07:56:26 Starting rules update...  Time: 2018-05-02 10:08:45 Downloading Snort Subscriber rules md5 file snortrules-snapshot-29111.tar.gz.md5... Checking Snort Subscriber rules md5 file... There is a new set of Snort Subscriber rules posted. Downloading file 'snortrules-snapshot-29111.tar.gz'... Done downloading rules file. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Checking Snort GPLv2 Community Rules md5 file... There is a new set of Snort GPLv2 Community Rules posted. Downloading file 'community-rules.tar.gz'... Done downloading rules file. Extracting and installing Snort Subscriber Ruleset... Using Snort Subscriber precompiled SO rules for FreeBSD-10-0 ... Installation of Snort Subscriber rules completed. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Copying new config and map files... Updating rules configuration for: WAN ... The Rules update has finished.  Time: 2018-05-02 10:09:13 Thanks

I still don't really understand what you want as an end game here.  Your last rule is simply going to pass everything on any port that is sourced from $MY_NETWORK to anywhere so long as the SYN and ACK flags are set on the TCP packet.  PASS rules have priority in the processing chain, and once a PASS rule matches for a packet no other examination takes place against any additional rules.  The packet is passed. Why don't you just filter by specific IP addresses (and maybe ports if possible) within the firewall itself and leave the IDS out of it?  Suricata and Snort rules typically are used to find malicious content, so they are designed to trigger when certain byte sequences are detected within the payload.  It seems like you are wanting to use to pass only selected content.  That is going to be a bit harder. Bill

The only issue I have had is the netmap_grab_packets and the only adjustment I have done is the potential solution that you have read which has been running smoothly except for the one encounter mentioned. Of course, mine wasn't a VM. I will update my thread later this week. I would not mess with dev.netmap.admode nor try to "tune" the NIC…I have found that the tuning made things only worst. Be also sure to disable the items recommended in System > Advanced > Networking.

Hey there, I was searching on the forums and the web to see which network adapters support and work with inline mode - netmap. I've found these and not sure if they're fixed in the current version. Inline mode doesn't permanently block an IP, only legacy mode does that. Inline mode breaks traffic shape, legacy mode doesn't Inline mode breaks VLANs, legacy mode doesn't Inline mode prevents packet leakage, legacy mode doesn't Apparently there are only a sub-section of hardware that fully supports Netmap… Netmap / FreeBSD has issues with Intel i340, i350/v2, i210, i211, i217 ,i219, PRO/1000, 82575/82576/82579/82580 and Realtek RTL8168B NIC's. @bmeeks: Netmap compatibility must exist at the software layer where the NIC driver meets the operating system… There have been (and probably still are) some issues/bugs in both the FreeBSD implementation of Netmap and in Suricata's use of Netmap. I have a Dell 0HM9JY Intel 82576 Gigabit ET quad port NIC (Intel PRO/1000 ET) and have the same error messages: 549.863394 [1071] netmap_grab_packets bad pkt at 91 len 2164 549.864619 [1071] netmap_grab_packets bad pkt at 95 len 2163 550.034152 [1071] netmap_grab_packets bad pkt at 197 len 2164 550.035448 [1071] netmap_grab_packets bad pkt at 199 len 2164 I have also turned off hardware-based checksums, TCP segmentation offloading and LRO (Large Receive Offloading), then reboot pfsense. Error still persists and doesn't seem to work properly or as intended.

@rebman77: I have to assume they have never tried their ruleset in Snort. I would agree …  :) Bill

+1 on what other respondents have said.  Running an IDS/IPS on the WAN is generally going to log a bunch of noise, and if you have no public-facing services and block all unsolicited inbound traffic, then you don't gain any security by running an IDS/IPS on the WAN. Better in most situations to run the IDS/IPS on the LAN.  Even then, you will want to let it run in non-blocking mode for a while to get a feel for any false positives that show up on your network.  There are generally quite a few centered around HTTP_INSPECT rules in Snort. Bill

Since those are hosted in the USA, and probably from CDNs with unpredictable address blocks, most likely the answer is 'no'.

OpenVPN or IPSec? I assume OpenVPN if pfSense is a client. Are you running Surucata in in-line mode? Steve

Thanks for the prompt reply Bill :) I mentioned the enc0 interface as you can do a packet capture and see unencrypted traffic from the VPN client via tcpdump. [2.4.3-RELEASE][admin@pfsense.xxxxxxxxxx.net]/root: tcpdump -i enc0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes 08:38:49.508431 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.62644 > pfsense.xxxxxxxxxx.net.domain: 62+ A? www.apple.com. (31) 08:38:49.508533 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.55246 > pfsense.xxxxxxxxxx.net.domain: 48200+ A? apple.com. (27) 08:38:49.508604 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.61700 > pfsense.xxxxxxxxxx.net.domain: 60069+ A? gateway.icloud.com. (36) 08:38:49.508671 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.59659 > pfsense.xxxxxxxxxx.net.domain: 32698+ A? www.icloud.com. (32) 08:38:49.508730 (authentic,confidential): SPI 0x0db585ec: IP pfsense.xxxxxxxxxx.net.domain > 172.16.9.3.55246: 48200 3/8/12 A 17.172.224.47, A 17.178.96.59, A 17.142.160.59 (460) 08:38:49.509125 (authentic,confidential): SPI 0x0db585ec: IP pfsense.xxxxxxxxxx.net.domain > 172.16.9.3.61700: 60069 9/4/0 CNAME gateway.fe.apple-dns.net., A 17.248.144.180, A 17.248.144.89, A 17.248.144.49, A 17.248.144.86, A 17.248.144.152, A 17.248.144.85, A 17.248.144.91, A 17.248.144.92 (336) 08:38:49.516628 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.61275 > pfsense.xxxxxxxxxx.net.domain: 40342+ A? metrics.icloud.com. (36) 172.16.9.3  = my iPhone https://www.freebsd.org/cgi/man.cgi?query=enc&sektion=4&manpath=FreeBSD+7.1-RELEASE I just wonder if snort was to enumerate enc0 as a valid interface I'd be able to alert / block IP addresses handed out to my IKEv2 clients.

I may have stumbled across a root cause. I enabled the Snort VRT rules, and as soon as I did CPU usage shot up through the roof and stayed there.  Disabling VRT and restarting Snort corrected it. I can't remember if the VRT rules are available in Suricata.  If they aren't, that may explain why I wasn't seeing the problem with Barnyard when using that instead of Snort. What's different about VRT? Is there something with that ruleset that could cause this? I'll keep an eye on things and let you guys know how things progress. And as always, thanks bmeeks for your contributions  :D

Good info Onyxfire!

@NRgia: Nice tutorial so to speak, maybe you could do a sticky post, in order for others to find it more easily in the future? Where to read more about rules tips & tricks ? "How to create Snort rules documentation", on their site is ok? There is some useful documentation on the Snort.org site.  However, to be honest, I've never found a great all-in-one location for this kind of information.  Bits and pieces are scattered all over.  As with lots of software, especially open-source and other "free" software, the developers spend more time on coding and adding features than creating documentation.  I am guilty of that as well with the Snort and Suricata packages. Bill

@mdes: First question, is Suricata in pfSense (inline mode) able to drop (or instruct PF to do it) a connection instead of blocking an IP? Second question, is Suricata in pfSense (inline mode) able to block destination (WAN) IP:port while it listens on LAN interface? Go read this post to answer question #1:  https://forum.pfsense.org/index.php?topic=135331.0. The answer to question #2 is "no, it can't do that".  Why would you want to do that anyway? Bill