SNMP and traditional monitoring — the protocol that pre-dates Prometheus and still earns its place · OPNsense

SNMP predates Prometheus by twenty years. SNMPv1 was published in 1988; Prometheus was released in 2012. In that gap, SNMP became the default protocol for routers, switches, printers, and UPSes — every device that wanted to be monitored at scale. The reason SNMP persists is not nostalgia: it is that every network device speaks it, every NMS knows how to poll it, and the protocol’s traps allow devices to push notifications without a persistent connection.

OPNsense supports SNMP via the net-snmp daemon. This lesson covers the daemon’s configuration, the v2c-versus-v3 question, the MIBs and OIDs the operator must know, and where SNMP fits in a modern stack alongside Prometheus.

Why SNMP, in 2026

The honest answer is: SNMP exists because every existing network management system supports it. The operator who runs Zabbix, LibreNMS, PRTG, Nagios, or any vendor NMS already has SNMP polling configured for the switches and routers. Adding the OPNsense firewall to the same NMS via SNMP requires zero new tooling. Prometheus, by contrast, requires deploying the exporter and building dashboards.

The trade-off is that SNMP’s data model is older and more awkward. Interface counters in SNMP are 32-bit and roll over at 4 Gbps; modern interfaces exceed this in seconds. Prometheus counters are 64-bit. SNMP traps are unreliable (UDP, no acknowledgement); Prometheus pushgateway is more robust. SNMPv2c sends the community string in cleartext; SNMPv3 fixes this but is harder to configure.

Configuring net-snmp on OPNsense

OPNsense ships the net-snmp package as a service. The configuration lives at Services → SNMP. The essential settings:

Enable — checkbox.
Location — free text, e.g. DC1, rack 12.
Contact — free text, e.g. noc@example.com.
Read community string (v2c) — the shared secret for read-only v2c access. Set to a non-default value.
SNMPv3 — username, auth protocol (SHA, MD5), auth password, priv protocol (AES, DES), priv password.

For most production deployments, SNMPv3 with SHA authentication and AES privacy is the right choice. SNMPv2c is acceptable on isolated management networks where the community string’s exposure is bounded.

The daemon listens on UDP port 161. The firewall rule on the management interface must allow UDP 161 from the NMS subnet.

MIBs and OIDs

SNMP exposes data as a hierarchical tree of identifiers. Each identifier is an OID (Object Identifier) — a dotted sequence of numbers like 1.3.6.1.2.1.2.2.1.10. The OID is the address; the value at that address is the data. MIBs (Management Information Bases) are the schema that translate OIDs into human names.

The two MIBs the operator must know:

IF-MIB (1.3.6.1.2.1.2.2.1.*) — the interfaces table. Every interface has an ifIndex; under each index are counters for bytes in (ifInOctets, OID …1.10), bytes out (ifOutOctets, OID …1.16), errors in (ifInErrors, OID …1.14), errors out (ifOutErrors, OID …1.20), drops in (ifInDiscards, OID …1.13), and so on.

Host-Resources MIB (1.3.6.1.2.1.25.*) — system resources. CPU load (hrProcessorLoad, OID …3.3.1.3), storage (hrStorageSize, hrStorageUsed), running processes.

Read-only / Safesnmpwalk ifInOctets— snmpwalk queries the entire subtree rooted at the given OID. Here it walks the ifInOctets column (bytes received per interface) and prints one line per interface. Counter32 is the 32-bit SNMP counter type — it rolls over at 2^32 bytes (~4 GB). For interfaces above 4 GB/s of sustained traffic, the counter wraps multiple times per hour and the NMS must handle the wrap. Most modern NMSs do; the operator should confirm.

$ snmpwalk -v2c -c public 192.0.2.1 1.3.6.1.2.1.2.2.1.10

IF-MIB::ifInOctets.1 = Counter32: 1842315234
IF-MIB::ifInOctets.2 = Counter32: 321456890
IF-MIB::ifInOctets.3 = Counter32: 1876543210
IF-MIB::ifInOctets.4 = Counter32: 0

Illustrative output

The operator reads SNMP by walking subtrees and reading the values. Most NMSs do this automatically and present graphs; the underlying mechanism is the same.

SNMP traps

Polling is the operator-initiated query: the NMS asks “what is the value of ifInOctets?”. Traps are the device-initiated notification: the device says “the link on interface 4 went down”. OPNsense can be configured to send traps to a trap receiver (UDP port 162 by default) when certain events occur.

The OPNsense trap configuration supports:

Link up / link down on interfaces.
CARP state change (master ↔ backup).
System threshold events via the bsnmpd integration.
Custom traps via shell scripts.

Traps are unreliable — UDP, no acknowledgement, lost in transit. The operator who relies on traps for paging has gaps. Traps are useful for “nice to have” notifications; for paging, use a polled threshold.

Where SNMP fits alongside Prometheus

A modern monitoring stack uses both:

SNMP for the devices that speak only SNMP — switches, routers, printers, UPSes, the existing NMS’s existing devices.
Prometheus for the devices that have modern exporters — OPNsense, Linux servers, applications.

The two feed the same NMS dashboards. Zabbix and LibreNMS accept both; the operator can have a single dashboard showing Prometheus-sourced OPNsense metrics alongside SNMP-sourced switch and router metrics. The integration is straightforward — both protocols are polled, both produce time-series data, and the NMS renders both.

The OIDs an OPNsense operator must know

The minimum OID set:

OID	Name	Meaning
`1.3.6.1.2.1.2.2.1.10.<idx>`	ifInOctets	Bytes received per interface
`1.3.6.1.2.1.2.2.1.16.<idx>`	ifOutOctets	Bytes sent per interface
`1.3.6.1.2.1.2.2.1.13.<idx>`	ifInDiscards	Inbound drops per interface
`1.3.6.1.2.1.2.2.1.14.<idx>`	ifInErrors	Inbound errors per interface
`1.3.6.1.2.1.25.3.3.1.3.<cpu>`	hrProcessorLoad	CPU utilisation per core
`1.3.6.1.2.1.25.2.3.1.5.<idx>`	hrStorageUsed	Disk used per storage
`1.3.6.1.4.1.12325.1.200.1.2.1`	pfStateTable	OPNsense-specific: state table count
`1.3.6.1.4.1.12325.1.200.1.3.1`	pfStateSearches	OPNsense-specific: state searches
`1.3.6.1.4.1.12325.1.200.1.4.1`	pfStateInserts	OPNsense-specific: state inserts

The first six are standard MIB-II / Host-Resources; the last three are the OPNsense enterprise tree (12325 is OPNsense’s IANA-registered enterprise number), which exposes PF state table data.

Read-only / Safesnmpget pfStateTable— An SNMPv3 poll for the OPNsense PF state table gauge. The community string and auth/priv passwords are supplied via command-line flags. The response is the OID followed by the type (Gauge32) and value (3127). A successful response confirms both authentication (SHA) and decryption (AES) work — the operator who has misconfigured either gets 'authentication failure' or 'decryption error' instead.

$ snmpget -v3 -u monitor -l authPriv -a SHA -A 'authpw' -x AES -X 'privpw' 192.0.2.1 1.3.6.1.4.1.12325.1.200.1.2.1

iso.3.6.1.4.1.12325.1.200.1.2.1 = Gauge32: 3127

Illustrative output

Summary

SNMP persists because every network device speaks it and every NMS knows how to poll it.
OPNsense ships net-snmp; the configuration lives at Services → SNMP.
SNMPv3 with SHA auth and AES priv is the production default; v2c is acceptable only on isolated management networks.
The OIDs that matter: IF-MIB for interfaces, Host-Resources MIB for CPU/memory, OPNsense enterprise OIDs for PF state.
SNMP and Prometheus can run side-by-side; the NMS consumes both.