Verify OPNsense Netmap IPS prerequisites before enabling prevention

Bottom line: Name the capture branch before enabling prevention. Review the interface and rule action together, then require separate evidence for an alert and an actual packet-discard result.

Source fact: what the authority says

The OPNsense IPS reference distinguishes PCAP IDS alerting, Netmap IPS and Divert IPS capture modes, and says a rule must have the drop action to discard a packet. For its Netmap interface guidance, the reference requires real interfaces supporting Netmap and says to enable IPS on the parent when using VLANs. It instructs administrators using IPS to disable all hardware offloading features in the interface settings. It also warns that WAN capture after IPv4 NAT shows translated firewall addresses rather than the originating internal machines.

What the source does not establish

This article limits its pilot to the documented Netmap branch, not Divert rule construction or a qualification of a network adapter. It does not establish complete threat detection, rule coverage or prevention from a single alert.

Applicability questions

• Which capture mode is selected, and which physical interface owns the VLAN traffic?
• What evidence establishes the adapter’s applicable Netmap support?
• What offload settings and rule actions are effective now?
• Where does translation occur relative to the proposed observation point?

DSE recommendation: controlled next steps

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

DSE recommends a capture diagram showing the internal test host, relevant VLAN parent, translation boundary and selected Suricata interface. Have the network owner explain what source identity should appear at that point. Resolve an unexpected translated identity before attributing an alert to a particular internal machine.

Record capture mode, interface settings and the selected test rule separately. Review the documented offload prerequisite during an approved maintenance window with a recovery route available. Avoid changing capture mode, rulesets and unrelated interface tuning together without expanding the plan.

Choose a harmless, expressly authorized rule-triggering test with the security owner. Write an alert expectation and a separate prevention expectation. Keep the rule’s enabled state and effective action in the record rather than inferring a drop from the presence of an event.

Use one reviewed interface and a small client population for the initial trial. Ask the application owner to identify a permitted control transaction and an acceptable interruption threshold. Preserve the initial settings and agree who will stop the pilot if normal traffic becomes unexplained.

Verification and evidence

Proposed verification: inspect the effective capture mode, parent assignment, offload settings and selected rule action against the plan. Perform the approved harmless trigger and correlate its event with the observed connection result at the named capture locations. Record an alert without the expected discard as a distinct finding.

Repeat the permitted control transaction and retain timestamps, rule identity and sanitized address observations. Do not interpret a quiet event list as proof that every threat was inspected. Accept only the bounded test result and keep adapter qualification and broader ruleset coverage in their separate reviews.

Official references

• OPNsense — Intrusion Prevention System — official product documentation; confirm the installed release and configuration.

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