Review OPNsense WAF main-rule identity before policy reuse

Bottom line: Review the rule objects before copying a WAF policy arrangement. Keep global main-rule identity, policy membership and location activation explicit so reuse does not conceal an ID and score-variable conflict.

Source fact: what the authority says

The OPNsense nginx WAF guide describes globally valid NAXSI main rules and basic rules commonly used in locations to whitelist a main-rule ID. The guide requires unique rule IDs and says the plugin supports score-based rules grouped into a policy that evaluates the aggregated score. It warns that main-rule reuse does not work because of an ID and score-variable conflict, and directs cloning the rules when needed. Applying the WAF to a location requires Enable Security Rules; Learning Mode logs requests without blocking them.

What the source does not establish

This article concerns the plugin guide’s rule-identity and reuse restriction. It does not prescribe a universal score, promise elimination of false positives or treat WAF configuration as a replacement for application security.

Applicability questions

• Which main-rule objects and IDs are proposed for each policy?
• Where would the same object be reused rather than cloned?
• Which locations are intended to activate each reviewed policy?
• What approved requests will distinguish observation from enforcement?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends drawing the proposed rule-to-policy-to-location relationships before copying a working arrangement. Give every main-rule object its own inventory row, including its ID and score reference. Mark intended reuse explicitly so the reviewer can identify the documented conflict before the configuration reaches a second policy.

For a proposed second-policy case, review a clone of the required rule against the original rather than assuming a shared object is supported. Reconcile the identity and score references with the current plugin instructions. Keep the clone’s intended purpose visible and avoid unrelated rule changes during this exercise.

Choose a small set of approved harmless requests with the application owner. Include a normal transaction and a request intended to exercise the selected rule. Write separate observation and enforcement expectations, and record the intended location. Do not use a universal score copied from another application as the acceptance criterion.

Make the location review a separate checkpoint after the object review. Preserve the previous policy membership and activation settings. Ask a second operator to trace each proposed location back to the correct rule objects, then agree a recovery condition for unexplained application disruption before permitting a broader deployment.

Verification and evidence

Proposed verification: inspect the final main-rule IDs, score references, policy membership and location selection against the reviewed map. Compare the original and cloned objects directly. Record any unresolved identity conflict as a failed configuration review, even if an unrelated application request still completes successfully.

Run only the approved request cases in the intended test location and retain the actual logged and connection observations. Label the effective learning or enforcement setting with each result. Have the application owner review unexpected normal-traffic results before expansion; do not infer complete application protection from this bounded rule exercise.

Official references

• OPNsense — nginx: Web Application Firewall — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.