IDS ruleset selection never persists — Download tab, config.xml, and API all fail to enable any ruleset

[uribear]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

No ruleset can be enabled under Services: Intrusion Detection: Administration: Download, through any of four independent methods tried (GUI, direct backend script execution, API, manual config.xml edit). <rules/> in config.xml stays permanently empty, and the settingsListRulesets API reports enabled: "0" for all 68 available rulesets no matter what is attempted. Suricata itself is healthy and reloads cleanly — it just has nothing to load (1 rule files specified, but no rules were loaded! in the Suricata log on every reload).

By contrast, the separate User Defined rule mechanism (Services: Intrusion Detection: Administration: User defined) works correctly and does persist — this scopes the bug specifically to the curated-ruleset enable/download subsystem, not the IDS rules pipeline as a whole.

First confirmed present in: OPNsense 26.7.3_11 (amd64).

To Reproduce

1. Go to Services → Intrusion Detection → Administration → Download.
2. Select one or more rulesets (tested with abuse.ch/Feodo Tracker and various ET open/* feeds).
3. Click Download & Update Rules.
4. No visible error appears. The configd log shows the action firing cleanly (generate template OPNsense/IDS → regenerates suricata.yaml, OPNsense.rules, etc. → update and reload intrusion detection rules).
5. Check wc -l /usr/local/etc/suricata/rules/OPNsense.rules — stays at 7 lines (header only) before and after.

Same negative result reproduced through three additional independent paths:

• Backend scripts run directly, bypassing configd/GUI entirely:

  python3 /usr/local/opnsense/scripts/suricata/rule-updater.py
  python3 /usr/local/opnsense/scripts/suricata/installRules.py
  

  Both exit cleanly with zero output; OPNsense.rules unchanged (7 lines).

• API settingsToggleRuleset / settingsSetRuleset (/api/ids/settings/toggleRuleset, /api/ids/settings/setRuleset), called directly against a ruleset filename (e.g. abuse.ch.feodotracker.rules) with enabled: 1. Both return {"result":"failed"} / {"status":"error"} with no further detail.

• Direct config.xml edit, bypassing GUI and API entirely — added <rules>abuse.ch.feodotracker.rules</rules> inside <IDS> (config backed up first), then re-ran the reload chain above. settingsListRulesets still reports enabled: "0" for that ruleset, and OPNsense.rules is still 7 lines.

Network path to the rule source was directly ruled out as a cause — curl from the firewall itself succeeds fully:

curl -v https://rules.emergingthreats.net/open/suricata-8.0/emerging.rules.tar.gz -o /tmp/test.tar.gz

TLS handshake OK, valid cert, HTTP/2 200, 5.34MB downloaded in ~2s.

Control test (works correctly, for contrast): Added a rule via Services → Intrusion Detection → Administration → User defined (Source IP any, Destination IP any, Action Alert, Description TEST rule diagnostic), Saved, Applied. Confirmed it reached the generated rules file:

grep -c "TEST rule diagnostic" /usr/local/etc/suricata/rules/OPNsense.rules
→ 1

This rules out a systemic Suricata-config-generation failure — the User Defined path correctly writes to and regenerates OPNsense.rules. Only the curated-ruleset (Download tab) enable/persist path is broken.

Expected behavior

Checking a ruleset in the Download tab and clicking "Download & Update Rules" should mark it enabled in the saved IDS configuration and populate OPNsense.rules with its downloaded content, exactly as the User Defined mechanism does for custom rules.

Describe alternatives you considered

• Reverting to a prior OPNsense version via the built-in revert tool was not tested — we do not have a known-good prior version to revert to, since this pair was first configured on 26.7.3_11. We cannot state a "last version where it did NOT exist" for that reason; this may be a long-standing issue rather than a regression introduced in this hotfix, and we'd appreciate maintainer input on whether this is reproducible on earlier 26.x/25.x releases.
• Tried the User Defined rule mechanism as a workaround (see control test above) — this does work and is usable as a stopgap for custom signatures, but does not substitute for the curated ET Open / abuse.ch feeds the Download tab is meant to provide.

Screenshots

Available on request — GUI screenshots of the Download tab (checkbox selection + "Download & Update Rules" button) showing no error and no effect were captured during triage but not yet attached; happy to add if useful.

Relevant log files

configd log excerpt showing the action chain firing without error despite no content being downloaded:

generate template OPNsense/IDS
[... regenerates suricata.yaml, OPNsense.rules, etc ...]
update and reload intrusion detection rules
request installable rules
request suricata rule metadata

Suricata's own log on every reload:

1 rule files specified, but no rules were loaded!

(engine restarts cleanly, threads created successfully — Suricata itself is not the problem)

Additional context

Also hit a separate but possibly related bug in the same build/session: /api/core/hasync/status/remoteService throws a PHP fatal error (Call to private method OPNsense\Core\Api\HasyncStatusController::remoteServiceAction() from scope OPNsense\Mvc\Dispatcher) — a method-visibility bug preventing that endpoint from ever completing. Mentioning in case it points to a broader pattern of controller/action wiring issues introduced in this hotfix line (26.7.3_2 → _11).

Environment

• OPNsense 26.7.3_11 (amd64)
• Suricata 8.0.6, IDS module in netmap (IPS) mode, monitoring WAN
• Two-node CARP HA pair, both nodes on identical firmware/package versions (bug reproduces identically on both)
• Not a plugin conflict as far as we can tell — Zenarmor (os-sensei) and Wazuh agent are also installed but operate independently of the IDS module

[sopex]

Take a look here:

20260725-1620-10.0526613.mp4