OPNsense Suricata IDS/IPS: Installation and Tuning Guide

OPNsense intrusion detection is Suricata, built into the core firewall with no plugin to install. Open Services → Intrusion Detection → Administration, tick Enabled, choose a capture mode (PCAP live for alert-only IDS, Netmap or Divert for inline IPS), select an interface, download ET Open and the abuse.ch rules, then click Apply.

The engine version tracks the firmware: OPNsense 26.7 shipped Suricata 8.0.6, and the 26.7.4_1 hotfix moved it to 8.0.7, according to the 26.7 release notes (checked October 2026). Running it inline (IPS mode) drops malicious traffic in-band. This setup is stage 6 of the self-paced OPNsense training path.

First, decide what you actually want. IDS mode (detection only) mirrors traffic and alerts — zero risk to connectivity, useful for visibility. IPS mode (inline) sits in the packet path and can drop traffic, which means a bad rule or an overloaded CPU can take your internet down. For a homelab, the sane progression is: run IDS-only for a week, review what fires, then switch to IPS with a curated rule set. Skipping the IDS-first phase is the most common way people end up disabling Suricata entirely after it blocks something legitimate.

A second decision: which interface. Running Suricata on WAN inspects traffic after NAT (you see the firewall’s public IP as the local side) and catches inbound/outbound internet threats. Running it on LAN sees real internal client IPs, which makes alerts far more actionable for “which device is infected” — but on a busy LAN it inspects east-west traffic too and costs more CPU. Many homelabs run it on LAN for attribution, and if you have already split traffic per the OPNsense VLAN configuration guide, the IoT or guest interface is usually the highest-value single place to point it. The OPNsense IPS manual adds that inline IPS on WAN is usually unhelpful, because the firewall already drops unsolicited inbound traffic. Do not run it on both WAN and LAN simultaneously unless you have CPU headroom; you’ll double the inspection load and may double-alert.

Choose a capture mode: PCAP, Netmap or Divert

Current releases replace the old “IPS mode” checkbox with a Capture mode setting, and OPNsense 26.1 (January 28, 2026) added a third option: the 26.1 release notes list Suricata 8 “with inline inspection mode using divert”. The mode you pick decides whether Suricata can drop anything and what your NIC must support.

For Netmap, check your driver against FreeBSD’s netmap(4) page, which lists native support in cxgbe, em, ix, ixl, re, vtnet and the iflib framework behind igb; Intel’s i225 and i226 chips use igc(4), also an iflib driver. For a NIC that is not fully supported, the IPS manual says to set the tunable dev.netmap.admode to 2 (System → Settings → Tunables) to force emulated mode, which the man page expects to perform about the same as native on 1 Gbit/s NICs. Card-by-card advice is in the best NIC for OPNsense guide.

Divert suits a NIC without netmap support, or a setup where only some flows need inspection. Nothing is inspected until a pass rule carries the Divert-to setting in Firewall → Rules [new]; the IPS then forwards or drops each diverted packet. Attach it to the specific pass rules you want inspected, not a broad pass-any rule on WAN that would pass everything it matches. If the new rules editor is unfamiliar, start with OPNsense firewall rules explained.

Hardware requirements

Suricata is CPU-intensive. Inline IPS on a 1 Gbps WAN needs at least:

• 4-core CPU (Intel J6412 or better)
• 4 GB RAM dedicated to OPNsense
• Multi-queue NIC drivers (most Intel i210/i225 cards)

OPNsense’s own hardware sizing page puts its recommended tier at a 1.5 GHz multi-core CPU, 8 GB RAM and a 120 GB SSD. It names the intrusion detection alert database among the features that write to disk, which is why the SD-card minimum tier is no place for Suricata.

An older J3160 box such as the Protectli FW4B sits in the entry tier: the planning estimates in the best hardware for OPNsense in 2026 guide put it well short of gigabit with Suricata inline, and its tiers show what it costs to keep inline inspection off the critical path.

ARM boards are out entirely: OPNsense does not run on a Raspberry Pi, because the project publishes amd64 images only.

Enable the built-in engine

No plugin is needed: the OPNsense IPS is based on Suricata and ships in the core system. Open Services → Intrusion Detection → Administration. The only related plugin is os-intrusion-detection-content-et-pro, and you install it only if you have an ET Pro subscription.

Configure interfaces

On the Settings tab:

• Enabled: ✓
• Capture mode: start with PCAP live mode (IDS) for the initial detection-only phase; switch to Netmap (IPS) or Divert (IPS) only after tuning (see the rollout note above). Netmap requires netmap-capable NIC drivers, and enabling it on an unsupported NIC will break traffic, so verify your NIC before flipping this. When you do go inline, disable all hardware offloading under Interfaces → Settings, as the manual requires for IPS mode.
• Promiscuous mode: leave unchecked unless you specifically need to inspect traffic not destined for the firewall. The exception is VLANs: inline IPS has to run on the parent interface, and Thomas-Krenn’s walkthrough enables promiscuous mode there so Suricata listens on the physical interface.
• Pattern matcher: Hyperscan where the CPU supports it; the Hyperscan reference requires SSSE3 at minimum on x86. Without Hyperscan, the manual recommends the Aho-Corasick Ken Steele variant, which performs better than plain Aho-Corasick on commodity hardware.
• Home networks: an advanced setting that defaults to RFC1918 space. The manual says to define custom ranges when your internal networks differ, and doing so is also what makes IDS on a NAT’d WAN meaningful. This is important — many ET rules are direction-aware (“from external to HOME_NET”), and a wrong HOME_NET definition produces both false negatives and noise.
• Interfaces: select the interface you chose (WAN or LAN, per the decision above). The field accepts several, but each one adds inspection load.
• Listeners: Divert mode only; the manual suggests one per CPU.
• Save and Apply.

Enable rulesets

On the Download tab:

ET Open is not ET Pro on a 30-day delay, a claim that still circulates on forums. Replying on the Netgate forum, the Emerging Threats team wrote that “our ET Open rulesets are updated daily. There is no ‘30 day’ delay introduced.” The real difference is volume and origin: the ETPRO Telemetry FAQ puts new signatures at a 5–10:1 ratio of ETPro to ETOpen each day, with rules built on Proofpoint’s proprietary research going only to ETPro.

Enable ET Open plus the abuse.ch SSL Blacklist and URLhaus feeds for a free starting point. Click Download & Update Rules. Then schedule automatic updates: in Schedule (or via System → Settings → Cron) add a daily rule-update job, ideally at a low-traffic hour, so signatures stay current without manual effort. After every rule download you must apply changes for them to take effect — downloading alone does not reload the engine.

Resist the urge to enable every available ruleset. More rules means more CPU and dramatically more false positives. ET Open plus those two abuse.ch feeds is a solid, low-noise baseline; expand only when you have a specific gap.

Alert vs Drop

Rules have two modes:

• Alert — log the event, pass the traffic
• Drop — block the traffic immediately (Netmap or Divert capture mode only)

Start with Alert for 1–2 weeks, review the alert log, then move clean-looking rules to Drop. Picking an IPS capture mode is not enough on its own: the manual says a rule’s action must be drop for the packet to be discarded, and it calls Policies the preferred way to change behaviour, rather than dozens of per-rule overrides:

1. On the Policies tab, click + and set a priority. When several policies match a rule, the first match with the lowest priority number applies.
2. Select the rulesets it covers, and narrow by rule metadata (affected product, deployment) if the vendor provides it.
3. Set New action to Drop (the alternatives are Alert and Disable), save, and Apply.
4. On the Rules tab, filter by matched_policy to see which rules the policy caught; rules changed by hand show as __manual__.

Tuning false positives

In the Rules tab, filter by SID to suppress noisy rules:

# Common high-noise rules to review first:
ET POLICY DNS Query to .TK domain
ET POLICY Dropbox Client Observed
ET INFO Executable Download

For known-good internal services triggering rules, there is no passlist tab. Add a rule on the User defined tab that matches the host or network, with the action set to Pass and the Bypass toggle enabled, or change the action of the affected rules through a Policy.

When Suricata watches several internal interfaces, the IPS bypass how-to uses nine such Pass + Bypass rules, covering every pairing of 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16, to speed up routing between local networks. The trade-off is that east-west traffic goes uninspected.

Monitoring alerts

Services → Intrusion Detection → Alerts. Key columns: timestamp, SID, severity, source/dest IP.

For persistent monitoring, ship logs to a syslog target and visualize with Grafana/Loki or an ELK stack. On the Settings tab, Enable syslog alerts sends alerts in fast-log format and Enable eve syslog output sends EVE JSON at info level; create the target under System → Settings → Logging / Targets, filtered on application suricata and level info. Drop events only reach the internal logger because of a Suricata limitation, so review blocks in the OPNsense GUI.

Verification

Confirm Suricata is actually inspecting traffic before you trust it:

1. Service is running: Services → Intrusion Detection → check the status; the dashboard widget should show the engine as active and rule count loaded.

2. It sees traffic and alerts: from a lab client behind the monitored interface, request the test page the Suricata quickstart uses:

   curl http://testmynids.org/uid/index.html

   With ET Open loaded, the expected alert is SID 2100498, “GPL ATTACK_RESPONSE id check returned root”. Confirm it appears on the Alerts tab and, in IPS mode with that rule set to Drop, that the request actually fails.

3. Rules loaded without error: check Services → Intrusion Detection → Log file for parse errors after an update — a malformed custom rule can silently prevent the ruleset from loading.

Troubleshooting Suricata on OPNsense 26.x

• Divert selected, zero alerts. First confirm that a pass rule with Divert-to set actually matches the traffic you are testing. A GitHub report against 26.7.3 on Proxmox virtio NICs described Divert inspecting nothing while PCAP alerted normally; an OPNsense developer could not reproduce it and pointed to a rule that does not match the traffic, since PCAP captures everything. If you virtualize, weigh VirtIO against PCIe passthrough using the Proxmox install guide.
• Custom YAML overrides stopped working. OPNsense 26.1 removed custom.yaml support; the release notes direct overrides to /usr/local/etc/suricata/conf.d.

Performance and when not to run IPS

Suricata’s CPU cost scales with throughput × rule count. On a low-power box (e.g., a dual/quad Atom-class CPU) inline IPS at gigabit with a large ruleset will saturate the CPU and become your bottleneck — latency rises and throughput drops. If your hardware can’t keep up, you have three honest options: run IDS-only (no drops, still useful), trim the ruleset to high-confidence categories, or only inspect WAN ingress rather than all LAN traffic. Do not run inline IPS on a NIC without netmap support, on an underpowered VM, or on a link you can’t afford to have go down without an out-of-band recovery path. IDS/IPS is a high-value control, but a misconfigured inline engine that drops legitimate traffic erodes trust fast — stage it deliberately. Signatures are also only one lens: if what you actually want is to see which applications and categories your devices are reaching, Zenarmor’s classification engine answers a different question and many homelabs run both. On hardware that cannot carry inline IPS at all, the cheapest control that still removes real traffic is DNS blocklisting in Unbound: a malicious or tracking domain that never resolves never becomes a flow for Suricata to inspect.

Want a platform comparison? FirewallCompare compares OPNsense vs pfSense IDS/IPS approaches side-by-side.

FAQ

is suricata free on opnsense

Yes. Suricata ships in the OPNsense core at no cost, and ET Open plus the abuse.ch feeds are free downloads. Proofpoint’s ET Pro Telemetry edition is also free if you install os-etpro-telemetry and share anonymized alert data. Only the full commercial ET Pro ruleset, loaded through os-intrusion-detection-content-et-pro with an oink code, costs money.

what version of suricata does opnsense use

OPNsense 26.7, released July 15, 2026, shipped Suricata 8.0.6, and the 26.7.4_1 hotfix that followed the September 15 release of 26.7.4 moved it to 8.0.7. The Suricata 8 branch and the Divert capture mode arrived with OPNsense 26.1 on January 28, 2026; the ET Open ruleset was upgraded to version 8.0 in 26.1.3 on March 4, 2026.

why is suricata not blocking anything on opnsense

Usually because nothing is set to drop. Netmap and Divert capture modes only discard packets whose rule action is drop, so selecting an IPS mode alone blocks nothing. Create a Policy that sets New action to Drop for the rulesets you trust, then Apply. In Divert mode, also confirm a firewall rule has Divert-to set.

does suricata work on opnsense in proxmox

Yes. The OPNsense manual says IDS mode is available on almost all virtual network types, and FreeBSD’s virtio driver has native netmap support. A September 2026 report of Divert inspecting zero traffic on Proxmox virtio NICs could not be reproduced by an OPNsense developer, who suspected a non-matching rule, so check your Divert-to rule first.