OPNsense Suricata IDS/IPS: Installation and Tuning Guide

Suricata is OPNsense’s built-in network IDS/IPS engine. Running it inline (IPS mode) drops malicious traffic in-band. This guide covers setup from scratch through basic tuning.

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. 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.

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)

On a Protectli FW4C (J3160), expect ~250–400 Mbps throughput with ET Open rules before CPU saturation. If that is short of your WAN speed, the best hardware for OPNsense in 2026 tiers show what it costs to keep inline inspection off the critical path.

Install the plugin

System → Firmware → Plugins → search os-suricata → Install.

After install: Services → Intrusion Detection → Administration.

Configure interfaces

On the Settings tab:

Enabled: ✓
IPS mode: leave off for the initial detection-only phase; enable it only after tuning (see the rollout note above). IPS mode requires netmap-capable NIC drivers — Intel igb/ix work; some Realtek and many virtual NICs do not, and enabling IPS on an unsupported NIC will break traffic. Verify your NIC supports netmap before flipping this.
Promiscuous mode: leave unchecked unless you specifically need to inspect traffic not destined for the firewall.
Pattern matcher: Hyperscan if your CPU supports it (Intel with SSSE3+, dramatically faster), otherwise Aho-Corasick.
Home networks: set this to your internal RFC1918 ranges. 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.
Save, then go to the Interfaces sub-tab and add the interface you chose (WAN or LAN, per the decision above). Each monitored interface is added individually here.

Enable rulesets

On the Download tab:

Ruleset	Cost	Notes
ET Open	Free	Good baseline, delayed vs ET Pro by 30 days
ET Pro	~$600/yr	Real-time, full threat intel
Abuse.ch SSL Blacklist	Free	SSL cert-based C2 detection
Abuse.ch URLhaus	Free	Malware URL blocking

Enable ET Open + both Abuse.ch 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 the 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 (IPS mode only)

Start with Alert for 1–2 weeks, review the alert log, then move clean-looking rules to Drop.

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: add a passlist (Intrusion Detection → Passlist).

Monitoring alerts

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

For persistent monitoring, ship logs to a syslog target (System → Settings → Logging / Logging Targets) and visualize with Grafana/Loki or an ELK stack. The OPNsense Reporting/Insight features also surface alert trends without external tooling.

Verification

Confirm Suricata is actually inspecting traffic before you trust it:

Service is running: Services → Intrusion Detection → check the status; the dashboard widget should show the engine as active and rule count loaded.
It sees traffic: generate benign traffic and confirm flow counters increase. The standard safe self-test is requesting the EICAR test string or browsing a known-flagged test URL from a lab client and confirming an alert appears in the Alerts log (and, in IPS mode, that the connection is actually blocked).
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.

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.