SNMP port guide: network monitoring on ports 161 and 162

SNMP has two main roles. An SNMP manager is the monitoring system that asks questions or receives notifications. An SNMP agent runs on the device being monitored and exposes values through a Management Information Base, or MIB.

For routine monitoring, the manager sends get, get-next, get-bulk, or set requests to the agent on UDP 161. For event-driven monitoring, the device sends traps or informs to the manager on UDP 162. Informs are acknowledged; traps are usually fire-and-forget.

UDP 161 is the port most teams mean when they ask whether the SNMP port is open. It must be reachable from the monitoring collector to each monitored device if polling is required. UDP 162 is the reverse direction for traps and informs from devices to the collector.

Because SNMP mostly uses UDP, simple TCP-only checks can miss real behavior. A TCP port checker is useful for general reachability patterns, but SNMP validation should include an SNMP-aware command or monitoring collector test against the exact community, user, and MIB object.

SNMPv1 and SNMPv2c use community strings that behave like shared passwords. They are still common, especially in older networks, but they do not provide strong authentication or privacy. If the community string leaks, an attacker may read sensitive inventory and topology data.

SNMPv3 adds user-based security, authentication, and optional privacy encryption. For new deployments, SNMPv3 with authentication and privacy should be the default. If SNMPv2c remains necessary, scope it tightly and use unique, non-default community strings.

Open SNMP only between trusted monitoring collectors and the devices they manage. Typical sources include NMS platforms, observability collectors, SIEM integrations, capacity planning systems, and dedicated trap receivers.

Do not expose SNMP to the public internet. SNMP can reveal interface names, device models, firmware versions, routing details, serial numbers, and performance counters. Writable SNMP access can be even more dangerous if set operations are enabled.

Before allowing SNMP, decide whether the device should support polling, traps, informs, or all three. Confirm the SNMP version, allowed source IPs, community strings or SNMPv3 users, authentication and privacy algorithms, and which MIB views are exposed.

A port check can show whether a path might be reachable, but SNMP success depends on protocol-level policy. Use snmpwalk, snmpget, snmpbulkwalk, or the monitoring platform itself to confirm that the expected OIDs return data and that unauthorized sources are refused.

On network devices, enable SNMP only on management interfaces or trusted VRFs where possible. Configure SNMPv3 users, restrict source addresses with ACLs, and define MIB views so the monitoring system sees only what it needs.

On Linux, net-snmp is commonly used. Configure snmpd to listen on the intended interface, define SNMPv3 users or restricted communities, and allow UDP 161 only from monitoring collectors. Trap receivers such as snmptrapd need UDP 162 opened on the collector.

On Windows Server, SNMP is legacy compared with modern telemetry options, but it still appears in older monitoring stacks. If enabled, restrict accepted hosts, avoid default community strings, and prefer newer agents or Windows-native monitoring where practical.

Start by confirming basic network reachability between the collector and the device. Then run snmpwalk or snmpget from the collector using the same SNMP version, credentials, and security settings your monitoring platform uses.

For traps, generate or wait for a known event and confirm that the collector receives it on UDP 162. If traps do not arrive, inspect device trap targets, source interface, routing, ACLs, NAT, collector firewall rules, and whether the collector is actually listening.

If polling fails, the agent may be disabled, listening on a different interface, blocked by an ACL, or rejecting the community or SNMPv3 user. If only some OIDs fail, the MIB view, device firmware, permissions, or monitoring template may be wrong.

If traps fail, the device may be sending to the wrong collector address, using the wrong source interface, or blocked by routing and firewall policy. Remember that polling and traps use opposite traffic directions, so one can work while the other fails.

Use SNMPv3 with authentication and privacy whenever possible. Disable default communities such as public and private, avoid write access unless it is truly required, and restrict allowed sources to monitoring collectors.

Keep device firmware and agents patched, log SNMP authentication failures, monitor query volume, and alert on unexpected sources. Treat SNMP data as sensitive because it can reveal enough infrastructure detail to help an attacker plan lateral movement.