SNMP Ports 161 and 162: Follow the Traffic, Not Just the Numbers

When SNMP monitoring fails, it’s tempting to open UDP 161 and 162 everywhere. But those ports serve different roles—and a polling response doesn’t go to UDP 162.

The useful question is: which machine is sending which kind of SNMP message, and where is it supposed to arrive?

The short version

• UDP 161: An SNMP agent on a managed device receives requests from a monitoring manager.
• UDP 162: A manager or notification receiver listens for traps and informs.
• Polling replies: Return to the source address and source port used by the manager’s request—not to UDP 162.

SNMPv1, SNMPv2c, and SNMPv3 commonly use these same default UDP ports. Implementations can be configured differently, so check the actual listener and destination if the defaults don’t fit your setup.

Trace the two traffic paths

Polling: manager to agent

A manager sends a query, such as a GET or GETBULK request, to the agent’s UDP 161. The agent replies to the address and source port the manager used for that request.

Monitoring manager ── request ──> Device agent : UDP 161
Monitoring manager <── response ── Device agent

That response path is why UDP 162 is not the “reply port” for polling. The manager’s request source port is selected by the manager; UDP 162 is used when a notification receiver is the destination.

Notifications: sender to receiver

A trap or inform is sent separately to the configured notification receiver, conventionally on UDP 162. An inform is acknowledged by its receiver; a trap is not. Both use the receiver’s notification port by default.

Device or notification source ── trap/inform ──> Receiver : UDP 162

If you’re only polling devices and don’t receive notifications, you generally don’t need inbound UDP 162 open on the monitoring system. If you do use notifications, configure the sender with the receiver’s address and port, then allow that traffic to reach the receiver.

Build firewall rules around the direction

For polling, allow the monitoring host to reach UDP 161 on the managed devices. For notifications, allow the configured senders to reach UDP 162 on the receiver. Restrict source addresses to your management network where possible rather than opening both ports on every machine.

For example, these UFW rules allow polling from one manager and notifications from a trusted subnet:

sudo ufw allow from 192.0.2.10 to any port 161 proto udp
sudo ufw allow from 192.0.2.0/24 to any port 162 proto udp

Replace the example addresses with your real management host or network. Apply rules on the systems and network paths that actually filter the traffic. A local firewall rule alone may not account for network ACLs, cloud firewalls, routing, or NAT; this guide to opening ports across Linux, Windows, routers, and cloud firewalls explains those different layers.

Opening a port doesn’t start or configure the SNMP agent, and it doesn’t guarantee a request will reach it. The service must be enabled, listening on the expected interface, and configured to accept the request.

Check listeners, then test the real path

On Linux, inspect UDP listeners on the system that should receive the traffic. For polling, that’s usually the agent on UDP 161; for notifications, it’s usually the receiver on UDP 162.

sudo ss -lunp | grep -E ':(161|162)\b'

On Windows, inspect local UDP endpoints with PowerShell:

Get-NetUDPEndpoint | Where-Object { $_.LocalPort -in 161,162 }

These commands show local endpoints. They do not prove that another host can reach them. UDP has no connection handshake, and firewalls can silently drop packets. For broader Linux listener checks, see how to check open ports with ss.

When possible, test an actual SNMP request from the monitoring host. With Net-SNMP tools installed, an authorized SNMPv2c read-only test can look like this:

snmpget -v2c -c YOUR_READ_ONLY_COMMUNITY -t 2 -r 1 DEVICE_IP sysUpTime.0

Replace the placeholders with the device address and an authorized community. Don’t put real community strings in shared shell history or logs. For SNMPv3, use the security options supported by your installed Net-SNMP version and the account configured on the agent.

A practical timeout checklist

If a query times out or notifications don’t arrive, check the relevant path rather than opening both ports indiscriminately:

1. Confirm the service and port. Is the agent or receiver enabled, listening on the expected interface, and using the expected port?
2. Check the direction. Polling goes to UDP 161 on the agent. Notifications go to the configured receiver, conventionally UDP 162.
3. Check the return path. Polling responses go back to the manager’s request source port. Stateful firewalls typically handle return traffic, but verify the actual network policy.
4. Check the sender and receiver settings. For notifications, confirm the destination address and port on the sender. For polling, verify the manager is using the right device address and SNMP credentials.
5. Check every filtering layer. Host firewalls, network ACLs, cloud rules, routing, and NAT can all affect reachability.
6. Check authorization. An open port doesn’t mean the agent will accept a request. Verify the SNMP version, credentials, access controls, and any source restrictions.

Keep SNMP access limited

Avoid exposing SNMP broadly to the public internet. Restrict it to trusted management networks, disable services you don’t use, and avoid default or guessable community strings. Where supported, prefer SNMPv3 with authentication and privacy configured. SNMPv3 normally uses UDP 161 and 162 too; its security features don’t require different default ports.

The key distinction is simple: 161 is for requests to agents; 162 is for notifications to receivers. Once you map those roles to the actual traffic path, firewall rules and troubleshooting become much more precise.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.