IDS no alterts

[dotsch]

Comming from pfSense, I have troubles to get the IDS got working.

I have not get any alerts on the WAN, some few on the LAN. Tried several different pattern matcher, promisc / non promisc, policies and rule enablements, but there are no or only a few alters in the log.

Also the EICAR test was not successful. No alert nor blocking.

 

[7queue]

I also have never seen any alerts no matter how I configure the system, Suricata alone on a test install or with other plugins.

Does anyone using IDS/IPS actually have it working properly showing alerts? Does anyone actually use IDS/IPS on OPNsense?

I wound up installing an IPFire system on the edge before the OPNsense system and Suricata is working just fine on that system.

[someone]

did you put your IP address in home network box in advanced settings on the administration page

[someone]

Is your IPS using a filter, to stop some bad guys
Also you may not see any till there are some
Most of my blocks are from blocklists, IP range blocks, and others
Snort community blocklist, honeypot blocklist, range blocks

[Beroyt]

Hello everyone,
I'm seeking help with a complex Suricata issue where it fails to inspect traffic on a bridged interface, despite the service being active. I have performed extensive diagnostics and believe this is a driver/netmap incompatibility issue.
System & Hardware:
OPNsense: 25.7.1_1
CPU: Intel i5 (14th Gen)
RAM: 32 GB
NICs: 8 x Intel I226-V 2.5G ports (using the igc driver)
LAN Configuration: A bridge0 interface that combines 6 of the 8 physical ports, the other 2 ports are on pppoe with an ONT.
The Core Problem:
Suricata, in any mode (IDS/IPS) and on any bridged interface, fails to generate any alerts. The Alerts tab is always empty, even with standard tests like EICAR or nslookup testmyids.com. The top -aSH command shows the suricata process running but with near-zero CPU usage (<1%), confirming it is not inspecting packets.
Diagnostic Timeline & Tests Performed:
Initial Setup: Configured Suricata in IPS & Promiscuous mode, with ET Open and Abuse.ch rulesets, and a Policy set to "Alert". Hardware Offloading (CRC, TSO, LRO) is disabled. The Home networks variable is correctly configured.
WAN Interface Test: Attempted to run Suricata on the WAN (PPPoE) interfaces. The service started but no test alerts were generated.
LAN (Bridge) Interface Test: Switched inspection to the logical LAN interface (assigned to bridge0). No alerts.
SSH Diagnostics: The top command revealed that Suricata was attempting to attach to bridge0, even though this was not a selectable interface in the GUI.
Tunable Test: Added a system tunable dev.netmap.ad_default_if with the value bridge0. This did not change the outcome. (The tunable has since been removed).
Individual Physical Interface Test: Attempted to monitor all 6 physical member interfaces of the bridge. No alerts.
Manual Startup Test:
Manually starting Suricata with suricata --netmap=bridge0 fails instantly with the error: netmap:-0/xT: invalid empty port name.
The exact same error occurs when attempting to start on a single physical interface (e.g., igc3).
However, starting in legacy compatibility mode (suricata --pcap=bridge0) works without errors, proving the issue is specific to the netmap driver.
Final Verification: The issue persists even after updating OPNsense and performing a clean reinstall of the os-suricata plugin. The eve.json log shows that Suricata correctly attaches to bridge0 (even without the tunable) and sees basic traffic like SSH, but the rule engine never triggers an alert.
Question:
Given that this is a fatal netmap driver error with my Intel I226-V NICs (both on the bridge and on individual ports), is this a known bug? Is there a specific system tunable for the igc driver or netmap that could resolve this incompatibility?

Thank you in advance for any assistance.

[someone]

A quick test
In user defined rules under Intrusion Detection
put 1.1.1.1 in source address
change action to drop
enter
click apply
wait 5 minutes
ping 1.1.1.1
wait 2 seconds and press ctl c to stop it
check alerts it should be there
remember to delete the rule and click apply

[someone]

If you dont change it to drop and leave it as alert
I let it ping at least 10 times
It shows up in alerts and in the log just once
With the action showing blocked or alert
Drop works the best for this test
Look for it manually in the alerts section
Or enter 1.1.1.1 in the search bar in the log file under informational
Cannot search 1.1.1.1 for some reason under alerts, bug in 25.7, other IPs work
in the search bar

[someone]

If you are using opnsense 25.1
Remember to change pattern matcher to hyperscan