Separate discovered OPNsense neighbors from a complete device inventory

Bottom line: Decide what the neighbors display is intended to prove before using it in an inventory report. Preserve the discovery settings and observation time alongside the device list, and investigate missing devices through a separately authorized method.

Source fact: what the authority says

The OPNsense neighbors guide describes discovery through ARP and NDP messages, with a persistent database and logging of changed IP-to-MAC mappings. The service listens only on Ethernet interfaces and skips tunnel, loopback and similar interfaces. With discovery enabled, the discovered-hosts table shows the database; otherwise it shows the current kernel ARP and NDP tables. The settings can limit discovery to selected interfaces and ignore selected networks.

What the source does not establish

This article concerns the documented neighbor observation methods, rather than a certification that every asset has been found. A device identity, ownership assignment or authorization decision needs evidence beyond its appearance in this display.

Applicability questions

• Is hostwatch enabled, and which interfaces and ignored networks are selected?
• Does the report describe the persistent database or the current kernel tables?
• Which expected devices belong to each observed Ethernet segment?
• What separate source establishes asset ownership and approved network presence?

DSE recommendation: controlled next steps

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

DSE recommends naming the report according to its actual scope, such as observations on selected Ethernet interfaces during a stated interval. Attach a redacted settings view. Avoid labeling an empty result as a clean network without reconciling it with the expected device population.

Prepare a proposed inventory comparison with one known workstation, one recently moved device and one device outside the selected interfaces. Record the expected source of evidence for each. Ask the network owner to explain an absent entry before changing discovery settings or broadening monitoring to another segment.

Treat an unexpected mapping change as an investigation lead. Compare the observed time, interface, IP address and MAC address with approved moves and independent records. Keep an unresolved identity separate from a confirmed unauthorized asset. Do not remove a working device from service solely to make the inventory match.

Assign a reconciliation owner for stale and missing entries. Preserve the original report when correcting asset records, and record whether the correction concerns discovery scope, observation timing or the independent inventory itself. Keep any device identifiers in an appropriately restricted operational record.

Verification and evidence

Proposed verification: on an approved segment, compare the named test devices with the discovered-hosts table and the configured collection scope. Record the selected mode and time for each observation. Include an intentionally out-of-scope device as a boundary check, without expecting the display to provide evidence it was not configured to collect.

If an approved address change is available in the test plan, compare its discovery-log entry with the authorized change record. Retain discrepancies and the follow-up method. Accept the report only for the stated scope; keep completeness and asset authorization as separate review decisions.

Official references

• OPNsense — Neighbors — 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.