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.
\nThe 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.
\nThis 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nRecord 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.
\nChoose 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.
\nUse 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.
\nProposed 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.
\nRepeat 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich capture mode is selected, and which physical interface owns the VLAN traffic?\nWhat evidence establishes the adapter’s applicable Netmap support?\nWhat offload settings and rule actions are effective now?\nWhere does translation occur relative to the proposed observation point?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nRecord 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.\nChoose 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.\nUse 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.\nVerification and evidence\nProposed 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.\nRepeat 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.\nOfficial references\n\nOPNsense — Intrusion Prevention System — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [OPNsense IPS reference](https://docs.opnsense.org/manual/ips.html) 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which capture mode is selected, and which physical interface owns the VLAN traffic?\n\n- What evidence establishes the adapter’s applicable Netmap support?\n\n- What offload settings and rule actions are effective now?\n\n- Where does translation occur relative to the proposed observation point?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nRecord 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.\n\nChoose 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.\n\nUse 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.\n\n## Verification and evidence\n\nProposed 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.\n\nRepeat 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.\n\n## Official references\n\n- [OPNsense — Intrusion Prevention System](https://docs.opnsense.org/manual/ips.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/", "url": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Verify OPNsense Netmap IPS prerequisites before enabling prevention", "item": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/#article", "identifier": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/", "url": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/", "headline": "Verify OPNsense Netmap IPS prerequisites before enabling prevention", "description": "The OPNsense IPS reference distinguishes alerting from packet drops and documents Netmap interface and offload prerequisites.", "abstract": "The OPNsense IPS reference distinguishes alerting from packet drops and documents Netmap interface and offload prerequisites. Check the capture branch before interpreting a prevention result.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich capture mode is selected, and which physical interface owns the VLAN traffic?\nWhat evidence establishes the adapter’s applicable Netmap support?\nWhat offload settings and rule actions are effective now?\nWhere does translation occur relative to the proposed observation point?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nRecord 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.\nChoose 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.\nUse 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.\nVerification and evidence\nProposed 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.\nRepeat 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.\nOfficial references\n\nOPNsense — Intrusion Prevention System — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:43+00:00", "dateModified": "2026-10-29T19:50:08+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/verify-opnsense-netmap-ips-prerequisites-before-enabling-prevention/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Verify OPNsense Netmap IPS prerequisites before enabling prevention" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 520, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Intrusion Prevention System", "url": "https://docs.opnsense.org/manual/ips.html" } } ] } }