Suricata hardware sizing
OPNsense IDS/IPS Hardware Requirements for Suricata
Suricata is one of the OPNsense features that can move a firewall from “runs on almost anything” to a workload that deserves deliberate CPU and NIC sizing. Inspection cost changes with traffic rate, packet size, rules, capture mode and logging. Inline prevention also interacts with Netmap behavior. This page explains those constraints, shows hardware tiers with current listings, and provides a calculator that avoids promising a fictional fixed gigabits-per-second number for a CPU model.
Quick answer
Size IDS/IPS from inspected traffic and rules, not WAN speed alone
OPNsense uses Suricata for IDS and IPS and identifies intrusion detection/prevention as a feature with major hardware impact. For IPS, the documentation instructs users to disable hardware offloading and notes current Netmap re-injection constraints. Buy CPU headroom, 8–16GB RAM for a modern feature-rich appliance, and NICs with verified FreeBSD/Netmap behavior. Then benchmark the exact ruleset and traffic path.
Live Amazon hardware
Hardware with extra CPU and NIC headroom for Suricata
Live groups emphasize N305/Core firewall appliances and known Intel NIC families. These are planning tiers, not certified IPS-throughput products. The catalogue cannot verify an advertised “10Gbps firewall” claim unless the listing actually documents that performance, so the UI shows hardware identity rather than invented benchmark badges.
Buying decision
For IPS, stronger hardware reduces risk but cannot remove software-path limits
N305 or Core i3/i5 is easier to justify than N100 when a large portion of multi-gig traffic will be inspected. More CPU helps Suricata and surrounding services, yet OPNsense’s current Netmap IPS path has a single-thread re-injection limitation. Choose hardware conservatively, control which interfaces/rules need inspection, and validate with production-like traffic.
Interactive planner
OPNsense IDS/IPS Hardware Sizer
Enter inspected bandwidth, IDS versus IPS mode, ruleset size, user scale and logging intensity. The tool returns a CPU/RAM/NIC tier without pretending it is a benchmark.
Rules and packet mix can shift performance dramatically. Use the output to shortlist hardware, then run a repeatable Suricata test on the final configuration.
Compatibility checkpoints
The Suricata hardware checklist
Inspected bandwidth
Size from the interfaces and flows Suricata actually sees. A 10GbE LAN does not imply 10Gbps of inspected traffic.
Capture mode
IDS and IPS use different paths. Netmap IPS has stricter interface behavior and documented scaling limits.
Ruleset breadth
More rules and more expensive signatures can increase CPU and memory demand. Enable policies that match the security objective.
NIC behavior
Real interfaces and driver/Netmap support matter for IPS. Verify the exact controller instead of relying on generic multi-gig labels.
IDS and IPS are related but not identical workloads
IDS observes traffic and generates alerts. IPS goes further by placing Suricata inline so matching traffic can be dropped. OPNsense exposes different capture modes, including PCAP for IDS and Netmap or Divert for IPS. That architectural difference changes both troubleshooting and performance expectations.
A hardware guide therefore should not quote one Suricata throughput number. Start by deciding whether you need alerting, prevention, or both on different interfaces. An IDS sensor on selected traffic can be much easier to size than inline prevention on every packet entering a busy routed network.
Inspect only the traffic that serves the security goal
Suricata does not need to watch every interface merely because it exists. OPNsense documentation discusses interface choice and points out that NAT can change what is visible on WAN. For many deployments, internal interfaces provide better context for identifying the actual host involved in a flow.
From a hardware perspective, narrower inspection also reduces load. If a 10GbE storage VLAN contains trusted replication traffic that does not benefit from general internet signatures, excluding that path can preserve CPU for riskier traffic. Security policy should drive inspection scope; hardware should support that policy rather than forcing you to inspect everything.
Ruleset size and rule quality matter
Suricata performance depends on what signatures are enabled and how they match traffic. OPNsense provides policy controls and several ruleset sources. Enabling every available category can increase work and alert volume without necessarily improving protection for your environment.
Build a policy around the protocols, assets and threats you care about. Start with a manageable rule set, tune noisy signatures, and measure CPU before expanding coverage. This produces a more useful capacity baseline than a generic benchmark created with a different set of rules.
Pattern matching is a major part of the CPU bill
The OPNsense IPS guide exposes pattern-matcher choices and notes that Hyperscan is the best option on supported platforms, with other algorithms available when it is not. Pattern matching is one reason Suricata can consume much more CPU than ordinary stateful filtering.
A faster CPU therefore helps, but the software configuration remains important. Before replacing hardware, confirm that the engine is using an appropriate matcher, that rule policies are intentional and that alerts are not being generated by irrelevant traffic. Capacity planning and tuning work together.
Netmap IPS has a documented scaling caveat
OPNsense’s performance documentation states that Suricata in Netmap IPS mode currently re-injects inspected packets into the host network stack through a single-thread-limited path. It explicitly says RSS provides no benefit to IPS under that limitation. This is critical context for buyers comparing CPUs by core count.
Eight cores can still help other services and parts of the Suricata workload, but they do not create a simple eight-way inline forwarding path. Favor strong overall CPU performance and realistic expectations. If a vendor claims a tiny appliance provides a particular multi-gig IPS number, ask what OPNsense version, packet sizes, rules and capture mode produced it.
Divert IPS changes the threading model
Current OPNsense documentation also offers Divert IPS mode and allows a listener count that is usually aligned with the number of CPUs. This gives administrators another architecture to evaluate, but it should not be mixed casually into Netmap benchmark conclusions. The modes are not interchangeable test conditions.
If you plan to use Divert mode, benchmark that exact setup. Note the listener count, rules, packet generator and interfaces. Hardware advice is only useful when the test configuration matches the deployment; otherwise the result is a number without operational meaning.
Memory should cover Suricata plus the rest of the firewall
Suricata needs memory for rules, flows and processing, while OPNsense still maintains states, DNS, the GUI and other packages. Eight gigabytes is a practical minimum purchase tier for a modern IDS-enabled home firewall, and sixteen gigabytes provides comfortable room for larger policies or user populations.
Memory is rarely the reason to buy 32GB by default. Watch actual usage and consider how much alert/reporting data is retained. When the choice is between excessive RAM and a stronger processor or better NIC, prioritize the component that your measurements identify as the bottleneck.
Local alert retention makes storage more relevant
The OPNsense minimum hardware notes exclude intrusion-detection alert databases from the no-disk-write minimum tier. That is an important clue: an IDS appliance can write much more data than a basic router. Alert retention, EVE logging and local reporting can turn a tiny boot drive into an operational constraint.
Use an SSD with comfortable free space and consider shipping logs to an external system when long retention matters. External logging can improve resilience and keep the firewall storage workload predictable. It also prevents a noisy event from consuming all local disk space.
NIC compatibility can determine whether IPS works cleanly
The IPS guide says Netmap IPS needs real interfaces supporting the required path and documents an emulated mode when a card is not fully supported. For a performance build, native controller support is preferable because emulation can add uncertainty.
This is why the live products on this page favor known Intel NIC families and filter out USB adapters. Verify the exact PCI device and driver after installation. Disable hardware offloading as OPNsense instructs for IPS, then test drops, VLAN behavior and interface counters under load.
Small packets are harder than big speed-test packets
A gigabit of 1500-byte packets represents far fewer packets per second than a gigabit of small packets. Firewalls make decisions per packet/flow, and inspection engines must parse protocol content. A bandwidth-only benchmark can therefore hide the workload that stresses packet processing.
When testing IDS/IPS hardware, include realistic packet distributions or at least multiple packet sizes. If your environment includes VoIP, gaming, many short web flows or IoT chatter, a large-packet synthetic test can overstate how comfortable the appliance will feel during real traffic.
Build a baseline before enabling Suricata
Measure ordinary routing on the final NICs and cabling first. Confirm there are no interface errors, driver problems or CPU-frequency issues. Then enable IDS with a known ruleset and compare. Finally test IPS if inline blocking is required. This staged approach separates network and Suricata effects.
Record CPU utilization, packet drops, latency and throughput. If plain routing is already weak, replacing rules will not solve the underlying problem. If routing is strong and IPS causes the drop, you have evidence to tune Suricata or move to a stronger hardware tier.
Hardware margin is a security feature when it prevents shortcuts
An overloaded inspection appliance creates pressure to disable rules, bypass traffic or stop logging simply to restore performance. Buying reasonable headroom reduces that temptation and makes future rule updates less disruptive. That does not mean buying the most expensive CPU; it means leaving margin above the measured normal load.
Revisit the benchmark after major OPNsense or Suricata upgrades and when traffic patterns change. Security engines evolve. A documented baseline lets you distinguish a software regression, a new rule cost and a genuine need for stronger hardware.
Questions people ask
OPNsense Suricata hardware questions
Does OPNsense use Suricata for IDS/IPS?
Yes. OPNsense integrates Suricata and provides IDS and IPS capture modes, rule policies and alerting.
How much RAM does OPNsense IDS/IPS need?
Eight gigabytes is a practical modern starting point; sixteen gigabytes offers more room for larger rule sets, users and other services. Measure your actual configuration.
Is N100 enough for OPNsense Suricata?
It can be enough for lighter inspected traffic and focused policies. Multi-gig inline workloads are easier to plan around N305 or stronger Core-class CPU headroom.
Does N305 double IPS performance over N100?
No such conclusion is justified. N305 has twice the core count, but current Netmap IPS re-injection has a single-thread limitation and rules/packet mix strongly affect performance.
Should I enable RSS for OPNsense IPS?
Current OPNsense performance documentation says RSS provides no benefit to the Netmap IPS path because re-injection is single-thread limited. RSS can still matter for other networking workloads.
What NIC should I use for OPNsense IPS?
Choose a controller with current FreeBSD/OPNsense and Netmap support. Intel NICs are a common starting point, but verify the exact revision and interface behavior.
Should IPS run on WAN or LAN?
The OPNsense guide explains that interface choice affects visibility, especially with NAT. Choose the interface based on what you need to identify and protect, not merely convenience.
Does OPNsense IPS require hardware offloading to be disabled?
Yes, the OPNsense IPS documentation instructs users to disable hardware offloading features in the interface settings when using IPS mode.
How much SSD space does Suricata need?
It depends on alert retention and local reporting. Keep comfortable space or ship logs externally; basic OPNsense boot requirements are much smaller than a log-heavy IDS deployment.
How should I benchmark IPS hardware?
Measure plain routing first, then IDS and IPS with the exact ruleset, interfaces and packet sizes you will use. Record drops, latency, CPU and temperatures in addition to throughput.
Official references and methodology
Verify current OPNsense and hardware requirements before deployment
This page treats Suricata performance as configuration-dependent. The sizing tool does not assign a fixed IPS throughput to N100, N305 or Core processors. It incorporates documented OPNsense capture-mode and Netmap constraints, while live hardware cards expose CPU and NIC evidence only. Production validation should use the intended interfaces, offload settings, rules, packet sizes and logging policy.
- OPNsense intrusion prevention system
- OPNsense performance and IPS notes
- OPNsense hardware sizing and setup
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, firmware, NIC revisions, link capabilities, appliance configurations and seller terms can change. Verify the exact delivered model and your platform documentation before deployment.