Snort vs Suricata on pfSense: Which IPS to Run in 2026

The answer to snort vs suricata on pfSense is Suricata for almost every network. Its engine spreads inspection across CPU cores, Emerging Threats publishes ET Open rules built for it, and its engine branch is still moving. pfSense’s Snort package is pinned to single-threaded Snort 2.9.20. Pick Snort only for OpenAppID application detection or native Talos rules.

The margin is narrower than forum threads suggest: both packages share netmap inline IPS plumbing, both lost their maintainer in 2025, and Suricata 7 reached end of life upstream in July 2026.

Snort vs Suricata on pfSense at a glance

Package versions come from pfSense’s ports tree on GitHub (devel branch), not the upstream projects.

The Suricata GUI number is not the engine version: the Makefile says 7.0.8, while pfSense’s development ports tree picked up the Suricata 8.0.4 engine in March 2026. The running engine depends on your CE or Plus release; the commands at the end show it.

Why does multithreading decide it for most pfSense boxes?

Because Snort 2 runs detection on one CPU core per process, and the pfSense package has no path to Snort 3. Cisco calls Snort 2’s “single-threaded nature” one of the most common complaints about it. Suricata runs several packet-processing threads, so on a four- or eight-core firewall the inspection load has somewhere to go.

Snort scales by process instead. Cisco’s Snort 3 adoption notes explain that Snort 2 “required loading the configuration and network map separately for each process,” so every extra inspected interface costs another full rule set in RAM. The same page calls Snort 2 packet-based and Snort 3 flow-based, a gap pfSense users cannot close.

Suricata’s runmodes documentation says the workers runmode “generally … performs the best.” The netmap capture docs warn that the multi-threaded setup “only works correctly if the NIC has symmetric RSS hashing,” because both directions of a flow must land on one thread. So a single big download will not light up eight cores; threads raise aggregate capacity across many flows, which is what a house full of phones, TVs and laptops produces.

Netgate’s hardware sizing guidance agrees that “Suricata is multithreaded” and warns that inspection packages “can lower the total potential throughput.” If a box loses line rate once inspection starts, the routing, VPN and IDS bottleneck breakdown explains where the cycles go, and finding the real bottleneck gives the order to check things in.

Which rule sets work with which engine?

Both packages download ET Open and Talos rules, but each engine only reads one dialect natively. Snort reads Talos rules and ET’s Snort 2.9 build; Suricata reads ET’s Suricata builds and parses most, not all, Snort 2 Talos rules. For free coverage, Suricata plus ET Open is the default.

The Snort package’s setup documentation lists Talos registered rules (free, released after 30 days or more), Talos subscriber rules (paid, twice-weekly), GPLv2 Community (free), ET Open (free), ET Pro (paid, almost daily) and OpenAppID detectors. Proofpoint’s ET open rules index keeps separate snort-2.9.0, suricata-5.0 and suricata-7.0.3 trees, so each package pulls a build written for its own parser.

Talos rules on Suricata are awkward. The package author’s sticky on Talos rules with Suricata explains that the Snort package picks the matching Talos snapshot automatically because it knows which Snort binary is running. Suricata cannot know that, so you type the snapshot filename, such as snortrules-snapshot-29200.tar.gz, and the sticky warns that enabling the Snort 3 rules download “will break your Suricata package install completely.” Rules Suricata cannot parse are logged to suricata.log and skipped; Snort quits on a rule syntax error.

Rules that load can still match differently. Suricata’s Differences From Snort page, written against the Snort 2.9 branch, notes that $HTTP_PORTS-style rules should become alert http rules, that urilen ranges are inclusive in Snort but not in Suricata, and that flowbits:isset is evaluated at a different point.

Is inline IPS any different between the two packages?

Barely. Both packages offer Legacy Mode, which adds an alerting host to a pf table after the fact, and Inline IPS Mode, which drops individual packets through FreeBSD’s netmap. The prerequisites and failure modes are the same for both.

• Legacy Mode blocks on any alert. Per the Snort 4.0 inline IPS post, “any alert can generate a block,” and you cannot mark some rules alert-only. Pass-list your LAN (say 192.168.10.0/24), DNS resolvers and management hosts before enabling Block Offenders.
• Inline mode needs DROP actions. Vendor rules ship as ALERT, and without changing them “you will get no blocks.” Convert whole categories with dropsid.conf on the SID Mgmt tab.
• The NIC needs native netmap. FreeBSD’s netmap(4) lists cxgbe, em, ix, ixl, re, vtnet and iflib drivers such as igb. The iflib-based igc driver behind Intel I225 and I226 ports is not named, so verify it on your hardware. Anything else falls back to emulation, “inferior to native netmap mode.”
• Hardware offloading goes off. The Suricata 3.0 inline announcement has you disable checksum, TCP segmentation and large receive offloading under System > Advanced > Networking.
• VLANs mean the parent interface. Per the inline IPS and VLANs notice, run on igb1, not igb1.30: netmap does not process 802.1Q tags, and a VLAN interface forces a slower emulated adapter.

Run the first week as IDS only, suppress false positives, then enable blocking. Put the switch-on date in the interface description so “temporary IDS-only” does not quietly become permanent.

Where each package wins and loses

Suricata wins on threading, native ET rules, port-agnostic HTTP, DNS and TLS detection, and rule features Snort 2 lacks per Differences From Snort: file extraction with hash matching, Lua scripting, TLS certificate inspection and the iprep IP reputation keyword.

Suricata loses on lifecycle. The project’s July 2026 release notice says “Suricata 7 has reached EOL,” with 7.0.17 the last release in the series. If your pfSense release still installs a 7.0.x engine, you are on an unsupported branch until Netgate ships 8.x for it.

Snort wins on OpenAppID, native Talos rules with automatic snapshot selection, and a pinned engine Cisco says it will support longest: its January 2026 end-of-life notice retired eight Snort 2 builds and told remaining users to move to 2.9.20.

Snort loses on age: single-threaded, packet-based, and no Snort 3 package in the pfSense package list. Cisco’s EOL policy says updates “cease 90 days following the notification of EOL.” No date exists for 2.9.20 yet, but when that notice lands, the package’s Talos feed has about a quarter left.

Who maintains these packages now?

Nobody by name. Bill Meeks, the long-time maintainer of both packages, announced a retirement from maintainer duties on the Netgate forum in 2025. Netgate developers have since committed housekeeping fixes to both GUI packages, most recently in February 2026, but neither is a core pfSense package.

So choose on the engine, not the GUI, and expect bug fixes rather than new toggles. Both packages run on CE and Plus, so the CE versus Plus decision is separate, except that pfSense Plus 24.03 dropped Suricata from the Netgate 3100 because it no longer builds for that 32-bit ARM platform.

Either engine only catches what someone already wrote a rule for, so track new disclosures through TechSentinel and confirm your feed has signatures for the ones that matter.

What you actually need

• Home network, one WAN, two to four VLANs, four or more cores: Suricata with ET Open. IDS on the LAN parent interface for a week, then Inline IPS Mode with DROP on the categories you have tuned.
• Small office paying for Talos or enforcing application policy: Snort with subscriber rules and OpenAppID, in Legacy Mode with a careful Pass List. Size the CPU knowing one core per interface does the inspection.
• Low-RAM or low-core hardware: inspect one interface, trim rule categories, and read workload sizing for VPN, IDS and state tables before buying.
• Everyone: one engine per interface, and ideally one per firewall.

Check what you are actually running

From a shell on the firewall:

pkg info | grep -Ei 'snort|suricata'
suricata -V
snort -V
top -aSH

pkg info lists the GUI package and the engine separately; the engine entry is what matters for Suricata 7 end of life. Under load, top -aSH shows Snort pinning one thread per interface and Suricata spreading work across its worker threads.

Then test through the inspected path to an iperf3 server on another VLAN:

iperf3 -c 192.168.20.10 -t 30 -P 1
iperf3 -c 192.168.20.10 -t 30 -P 8

One stream shows the per-thread ceiling; eight show whether the extra threads earn their keep. For a baseline, stop the engine on its Interfaces tab, run both tests, then restart it.

FAQ

can i run snort and suricata at the same time on pfsense

You can install both, but do not run them on the same interface. Two engines inspecting identical traffic pay twice in CPU and RAM for overlapping alerts, and a mystery block means checking two tools. Pick one engine per firewall: Suricata for most networks, Snort for OpenAppID or native Talos rules.

does pfsense support snort 3

No. The pfSense Snort package depends on Snort 2.9.20 or later, and Netgate’s package list has no Snort 3 package for CE or Plus. Cisco’s January 2026 end-of-life notice tells Snort 2 users to run 2.9.20, the build it will support longest, and no retirement date has been published.

how much ram does suricata need on pfsense

At least 1 GB for Suricata itself, according to Netgate’s hardware sizing guidance, and some configurations need 2 GB or more. That figure excludes RAM for the operating system, firewall states and other packages. More inspected interfaces and enabled rule categories push it higher, so size for the ruleset you will run.

should i run suricata on wan or lan in pfsense

LAN, for most networks. On WAN the engine sees traffic before NAT, so alerts carry public addresses and include internet noise your firewall rules would drop anyway. On the LAN parent interface, alerts name the internal host, such as 192.168.10.23, that misbehaved. Inspect WAN only if you need visibility into pre-filter traffic.

Related across the network

• How to Install Snort on pfSense: Rules and Blocking Modes — pfsenselab.com
• pfSense Suricata vs Snort: Which IDS/IPS to Choose — pfsenselab.com