"
OPNsense (recent version), Suricata 8.0.6
Hardware: N100 mini PC, 4x Intel igc NICs
WAN: PPPoE (pppoe0 over igc1)
Suricata configured for WAN-only monitoring, ~20 rulesets enabled (abuse.ch feeds + ET Open categories, ~150k+ signatures total)
Zenarmor (Sensei) also installed, using netmap on a separate interface
Issue 1: eve.json never populated
Suricata starts cleanly (confirmed via configctl ids status and pgrep). stats.log updates normally, showing active flow processing (non-zero packets, flows checked, zero drops). eve-log is enabled in the generated suricata.yaml with a standard config (filetype: regular, filename: eve.json, types: alert/anomaly/drop/ssh).
The file stays at 0 bytes indefinitely, even after 60+ seconds of real traffic and repeated requests to testmynids.org (designed to trigger GPL SID 2100498). No "rules loaded" or signature count message appears anywhere in suricata_YYYYMMDD.log.
Things tried, none of which changed the outcome:
Switching interface binding from raw physical igc1 to the logical pppoe0
Removing a duplicate syslog eve-log output block, leaving only the file-based one
Deleting and recreating the pidfile and eve.json to rule out stale locks
Full system reboot
Full package reinstall via pkg install -f, including wiping /usr/local/etc/suricata and /var/log/suricata entirely before reinstalling
Issue 2: Netmap/inline capture mode breaks WAN entirely
Switching Capture mode to "Netmap (inline/IPS)" causes complete loss of internet connectivity (100% packet loss pinging 1.1.1.1/8.8.8.8) within seconds of starting. Suspect a conflict with Zenarmor/Sensei's own netmap usage on a different interface of the same box, though unconfirmed. Reverting to "PCAP live mode (IDS)" immediately restores connectivity.
Question: Has anyone seen eve.json fail to populate under 8.0.6 specifically, despite clear evidence the engine is processing traffic? And is netmap mode known to conflict with other netmap consumers (e.g., Zenarmor/Sensei) on a different interface of the same box?
Hardware: N100 mini PC, 4x Intel igc NICs
WAN: PPPoE (pppoe0 over igc1)
Suricata configured for WAN-only monitoring, ~20 rulesets enabled (abuse.ch feeds + ET Open categories, ~150k+ signatures total)
Zenarmor (Sensei) also installed, using netmap on a separate interface
Issue 1: eve.json never populated
Suricata starts cleanly (confirmed via configctl ids status and pgrep). stats.log updates normally, showing active flow processing (non-zero packets, flows checked, zero drops). eve-log is enabled in the generated suricata.yaml with a standard config (filetype: regular, filename: eve.json, types: alert/anomaly/drop/ssh).
The file stays at 0 bytes indefinitely, even after 60+ seconds of real traffic and repeated requests to testmynids.org (designed to trigger GPL SID 2100498). No "rules loaded" or signature count message appears anywhere in suricata_YYYYMMDD.log.
Things tried, none of which changed the outcome:
Switching interface binding from raw physical igc1 to the logical pppoe0
Removing a duplicate syslog eve-log output block, leaving only the file-based one
Deleting and recreating the pidfile and eve.json to rule out stale locks
Full system reboot
Full package reinstall via pkg install -f, including wiping /usr/local/etc/suricata and /var/log/suricata entirely before reinstalling
Issue 2: Netmap/inline capture mode breaks WAN entirely
Switching Capture mode to "Netmap (inline/IPS)" causes complete loss of internet connectivity (100% packet loss pinging 1.1.1.1/8.8.8.8) within seconds of starting. Suspect a conflict with Zenarmor/Sensei's own netmap usage on a different interface of the same box, though unconfirmed. Reverting to "PCAP live mode (IDS)" immediately restores connectivity.
Question: Has anyone seen eve.json fail to populate under 8.0.6 specifically, despite clear evidence the engine is processing traffic? And is netmap mode known to conflict with other netmap consumers (e.g., Zenarmor/Sensei) on a different interface of the same box?
