Suricata installation on OPNsense — the plugin, the interfaces, the home net, and the rule set

Suricata on OPNsense is a plugin, not a built-in service. The operator installs the plugin, configures the interfaces to monitor, sets the HOME_NET variable to match the local network, enables the rule set, and verifies the engine is inspecting traffic. A misconfigured Suricata installation will appear to run while inspecting nothing — the engine starts, the rules load, but the HOME_NET is wrong or the interfaces are wrong, and the engine produces zero alerts. This lesson covers the steps to install Suricata correctly and the verification commands that prove it is working.

Install the plugin

The Suricata plugin is os-suricata (System → Firmware → Plugins). The install:

1. Navigate to System → Firmware → Plugins.
2. Search for suricata (or os-suricata).
3. Click Install. The plugin pulls in the Suricata binary, the OPNsense plugin code, and a default configuration file (/usr/local/etc/suricata/suricata.yaml).
4. After install, the plugin adds a top-level menu item: Services → Intrusion Detection.

The plugin installs the ET Open ruleset by default but does not enable any signatures. The operator must enable rule categories in the GUI.

Configure HOME_NET

The HOME_NET variable defines what the operator considers “their network”. Suricata uses HOME_NET to scope signatures that only apply to internal traffic (e.g., a signature that fires on a specific LAN subnet). A wrong HOME_NET means signatures do not fire — they evaluate to false because the traffic is not on the configured subnet.

The default HOME_NET is 192.168.0.0/16 — the RFC 1918 private range. The operator changes it to match the actual network: the LAN prefix(es), the DMZ prefix(es), and any other internally-routed networks. The configuration in OPNsense: Services → Intrusion Detection → Settings → HOME_NET.

HOME_NET = "[10.0.0.0/24, 10.1.0.0/24, 192.168.50.0/24]"
EXTERNAL_NET = "any"

The HOME_NET must be a list of prefixes that match what the operator’s interfaces actually carry. A HOME_NET of 10.0.0.0/8 (the entire /8) is technically a superset of the operator’s network but produces false positives on traffic the operator does not care about. The discipline: HOME_NET matches the operator’s actual subnets, not a superset.

Configure the interfaces

Suricata needs to know which interfaces to monitor. The configuration: Services → Intrusion Detection → Interfaces → add an interface.

The common choices:

• WAN interface — Suricata inspects all incoming traffic from the Internet. This is where most external attacks arrive. The cost is highest because the WAN carries the most traffic.
• LAN interface — Suricata inspects traffic from internal hosts. Useful for detecting compromised hosts talking to C2 servers or exfiltrating data. The cost is lower (LAN traffic is usually smaller than WAN).
• DMZ interface — Suricata inspects traffic to and from the DMZ. Useful when the DMZ hosts public-facing services.

A typical production deployment monitors the WAN and the LAN. The operator who monitors every interface — including the management interface — has too much data; the operator who monitors only the WAN misses lateral movement on the LAN.

Enable the rule sets

OPNsense exposes the Emerging Threats rulesets through Services → Intrusion Detection → Rules. The categories:

The operator enables the categories that match the threat model. A typical deployment enables emerging-attack_response, emerging-botcc, emerging-dns, emerging-exploit, emerging-malware, and emerging-trojan. A network that hosts public web servers also enables emerging-web_server.

IDS versus IPS

OPNsense supports both modes. The setting is per-interface: Services → Intrusion Detection → Interfaces → Mode. The choice:

• IDS mode — Suricata captures a copy of the traffic on the interface and inspects it. The original traffic is not affected. False positives produce alerts, not dropped packets.
• IPS mode — Suricata sits inline (using netmap or similar) and inspects every packet. The engine can drop or reject packets that match signatures. False positives drop legitimate traffic.

The decision tree from the previous lesson: IDS for visibility without risk; IPS only when the operator has the operational capability to tune the signatures and respond to the alerts.

Verify the installation

After configuration, the operator verifies Suricata is running and inspecting traffic:

$ ps -ax | grep suricata | grep -v grep; echo '---'; configctl suricata status; echo '---'; tail -20 /var/log/suricata/suricata.log

1234  -  S    0:42.18 /usr/local/bin/suricata --pidfile /var/run/suricata.pid -c /usr/local/etc/suricata/suricata.yaml -i igb0 -l /var/log/suricata/ -D
---
suricata 1234 1 0 12:34 ? 00:00:42 /usr/local/bin/suricata
status: running
rules loaded: 28473
---
12:34:56 - Suricata 7.0.10 started
12:34:57 - Bytes received: 0 (kernel: 0)
12:34:58 - Pcap capture thread stats: pkts 1234, drops 0
12:35:00 - Stream thread stats: ...
12:35:30 - Alert: 2024001 - ET MALWARE Cobalt Strike beacon (rev:2) [1:2024001:2]

The verification checklist

The post-install verification is a four-step checklist:

A deployment that passes all four checks is working. A deployment that fails any one has a configuration issue.

Summary

• Suricata on OPNsense is the os-suricata plugin; install through System → Firmware → Plugins.
• HOME_NET must match the operator’s actual subnets — wrong HOME_NET means signatures do not fire.
• Configure the interfaces to monitor; a typical deployment is WAN + LAN.
• Enable rule categories that match the threat model; not every category is appropriate for every network.
• IDS mode for visibility; IPS mode only when the operator has the operational capability to tune.
• The verification checklist: process running, rules loaded, capturing packets, alerts firing.