Hi Jarlei,
Excellent write-up, and thank you for sharing this post-mortem! This is exactly the kind of real-world feedback that saves the next person a massive amount of work and headache.
You hit the nail on the head regarding the underlying mechanics. The re driver for Realtek hardware and netmap have a notoriously rocky history in the FreeBSD/pfSense ecosystem. When Snort hooks into Netmap for inline IPS mode, it expects to see raw, untouched frames. If hardware checksum offloading, LRO, or TSO are left enabled, the Realtek NIC tries to front-load that processing. Netmap doesn't know what to do with those modified mbufs, panics, and triggers the exact log loop and immediate console lockup you experienced.
Your recovery steps were spot on, too. Dropping to the physical shell, killing the process, and flushing the tables is often the only way back into the house when the web GUI and management interface go completely dark.
You are making the absolute right move by switching to the Intel I350-T4. The igb driver for those Intel enterprise chips has native, robust multi-queue support and handles Netmap effortlessly. Even with the Intel card, it is still standard best practice in pfSense to explicitly disable hardware checksums, TSO, and LRO under System > Advanced > Networking when running Inline Mode to ensure packet processing is handled cleanly by the OS and the DAQ engine.
Once you have that I350 dropped in and the offloads disabled, you'll have a rock-solid hardware foundation. From there, you can safely circle back to using PulledPork to gradually step up from passive alerts to active drops without the hardware pulling the rug out from under you.
Keep us posted on how the deployment goes with the new Intel NIC!
Best regards,
Michael
WINSNORT.com Management…
--
******************** Established ~ 2003 **********************
* FREE Windows Intrusion Detection System (WinIDS) Tutorials *
* ~~ FREE Windows Support Forums ~~ *
* Visit @ https://winsnort.com *
* Snort: Open Source Network IDS - http://snort.org *
**************************************************************
From: Suporte Lapin Têxtil <suporte@lapintextil.com.br>
Sent: Tuesday, June 23, 2026 1:18 PM
To: Michael Steele <winsnort@winsnort.com>; snort-users@lists.snort.org; 'Jonathan Lee' <jonathanlee571@gmail.com>
Subject: Re: [Snort-users] Ruleset advice for beginners
Hi everyone,
I wanted to share a real-world "beginner scenario" post-mortem that happened in my environment today, which perfectly aligns with Michael's advice on testing and hardware dependencies.
I recently tried to deploy pfSense-pkg-snort (Snort 2.9.x) on a pfSense CE 2.8.1 box (FreeBSD 15-CURRENT base). Upon a clean installation with a restored ruleset config, the entire network collapsed instantly, and the local console became completely unresponsive, flooded with the following loop:
"netmap_transmit [xxxx] re1 drop mbuf that needs checksum offload"
What I learned the hard way:
1. Hardware Matters: The firewall was running on Realtek PCIe GbE chips (re driver). The combination of Snort trying to hook into Netmap while Hardware Checksum Offloading, TSO, and LRO were still active globally caused a fatal buffer conflict.
2. The Crash: Netmap dropped every single packet before it hit the OS stack because the Realtek hardware was passing segmented/checksummed packets that the DAQ engine couldn't parse.
3. The Fix: I had to drop to the physical shell, run 'killall -9 snort', flush the 'snort2c' firewall table, and completely purge the package via 'pkg delete'.
As Michael perfectly stated, you cannot just drop a premium ruleset out-of-the-box and flip the block switch. In the pfSense/FreeBSD ecosystem, running Snort/Suricata in Inline Mode (Netmap) on Realtek hardware without strictly disabling all hardware offloading beforehand is a recipe for a network-wide outage.
We are now migrating the box to a dedicated Intel I350-T4 quad-port NIC to handle the multi-queue and Netmap requirements properly before attempting IPS again.
Hope this helps any other beginners troubleshooting console freezes with Netmap and 're' drivers!
Best regards,
Jarlei
Em 22/06/2026 13:35, Michael Steele via Snort-users escreveu:
There is no way to download a pre-packaged, out-of-the-box ruleset tailored perfectly to a specific environment right from the start.
While the Talos Subscriber ruleset gives you rapid, premium threat updates, even those rules default primarily to alert actions. This is intentional; if a ruleset dropped traffic by default, it would instantly break legitimate services on a home network the moment a false positive triggered.
PulledPork is exactly the tool you need to change this behavior, but its base policies (Connectivity, Balanced, and Security) are only the starting point. To move from passive alerts to active blocking (drop actions), you need to configure PulledPork to rewrite the rule states for you.
Building a custom ruleset that matches your specific network profile will take a little work, but here is the general approach to get you started:
1. Enable Inline Dropping in Snort
First, make sure Snort is actually configured to drop traffic. If Snort isn't running in inline mode (using DAQ modules like afpacket or nfq), changing the rules to drop won't do anything—it will still only log an alert. you need to ensure your execution mode supports blocking.
2. Leverage PulledPork's Modification Files
Instead of editing the massive ruleset manually every day (which gets overwritten on every update), you use PulledPork’s built-in state modification files: dropsid.conf, enablesid.conf, and disablesid.conf.
- dropsid.conf: You can add specific Signature IDs (SIDs) or entire rule categories here. PulledPork will automatically change the action from alert to drop every time it downloads a new update.
- disablesid.conf: Use this to turn off noisy or irrelevant rules (like specific server vulnerabilities if you aren't running those servers at home) to reduce overhead and false positives.
3. Start Small and Tune
Start by using dropsid.conf on highly reliable, high-severity categories (like known malware command-and-control communication or active exploits). Watch your logs closely for a week to catch false positives before expanding your drop list.
Tailoring a ruleset is an iterative process, but utilizing PulledPork to manage the rule modifications is the standard, efficient way to handle it.
WINSNORT.com Management…
--
******************** Established ~ 2003 **********************
* FREE Windows Intrusion Detection System (WinIDS) Tutorials *
* ~~ FREE Windows Support Forums ~~ *
* Visit @ http://winsnort.com *
* Snort: Open Source Network IDS - http://snort.org *
**************************************************************
Best regards,
Michael...
You have to set block on alert and inline mode or legacy mode
About a year ago I installed snort3 and pulledpork on ubuntu 24.04 to provide better protection on my home network.
I registered and used the LightSPD_ruleset, rule_mode=simple, ips_policy=balanced
Got it all working, and auto updating the LightSPD ruleset everyday.
At the start, I was checking the log $ tail -f /var/snort/alert_json.txt to see if it was working.
So I felt very happy and secure.
Then the other day I checked the log file a bit more and noticed the log file only had alert warnings and no rule actions like block or drop etc.
So then I checked the LightSPD_ruleset and noticed that by default the rule actions are all set to alert warnings.
Which means I have to monitor the log file and customize the rules myself.
While I’d call myself a linux enthusiast, I don’t have the expertise to do that.
Is there a way to get a rule set suitable for a home network?
I’m thinking there might be a community rule set suitable or pay for a subscribed Talos ruleset.
I’m assuming the subscribed ruleset comes with rule actions to provide protection, and instant threat updates.
Are my options correct?
Advise please.
PS: I am new to this mailing list.
Peter Lyons
_______________________________________________
Snort-users mailing list
Snort-users@lists.snort.org
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users
To unsubscribe, send an email to:
snort-users-leave@lists.snort.org
Please visit http://blog.snort.org to stay current on all the latest Snort news!
Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette
_______________________________________________
Snort-users mailing list
Snort-users@lists.snort.org
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users
To unsubscribe, send an email to:
snort-users-leave@lists.snort.org
Please visit http://blog.snort.org to stay current on all the latest Snort news!
Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette