Wondering which SNMP port to open on your firewall? Agents listen for requests on UDP port 161, and managers listen for traps and informs on UDP port 162. TLS and DTLS mappings use other ports.
This guide is part of our series on SNMP, the protocol used to monitor routers, switches, servers and printers.
| Item | Value |
|---|---|
| Agent (command responder) port | UDP 161 |
| Notification receiver port | UDP 162 |
| Optional SNMP over TCP ports | TCP 161 and TCP 162 |
| SNMP over TLS/DTLS ports | 10161 (requests) and 10162 (notifications) |
| Minimum message size to accept over UDP | 484 octets |
The UDP figures come from RFC 3417 and the TLS ports from RFC 6353. Standards and registries can be updated, so check those sources before you rely on the figures.
What the two main SNMP ports do
SNMP uses two well-known ports because traffic flows in two directions. Polling goes from the manager to the device, while alerts go from the device to the manager.
- UDP 161 is where an agent (the standard calls it a command responder) listens for get, set and walk requests.
- UDP 162 is where a manager or trap receiver (a notification receiver) listens for traps and informs sent by devices.
Your monitoring server sends a query to port 161 on the device. Replies come back to whatever source port the manager used for the query, not to 161.
When a switch raises a trap, such as a link going down, it sends it to port 162 on the receiver. So the device needs an outbound path to the manager on 162, and the manager needs an outbound path to the device on 161.
Are these ports a rule or a suggestion?
The wording is softer than most people expect. As of the December 2002 text of RFC 3417, the standard says it is “suggested that administrators configure their SNMP entities supporting command responder applications to listen on UDP port 161.”
It adds the same suggestion for notification receivers on UDP port 162. That is why many products let you change the port, and why you may find an agent on a non-standard port to reduce scanner noise.
If you change a port, record it. Every manager polling that device has to be told, and trap senders must be pointed at the new receiver port.
SNMP over TCP
SNMP normally runs over UDP, but RFC 3430 defines an optional mapping over TCP. It says it is “RECOMMENDED that administrators configure their SNMP entities containing command responders to listen on TCP port 161 for incoming connections.”
The same document recommends TCP port 162 for notification receivers. Any engine that supports TCP “MUST also implement the SNMP over UDP transport mapping,” so UDP stays the baseline.
In practice, most monitoring tools still poll over UDP. Only open the TCP ports if a device or tool you use documents TCP support.
Ports for encrypted SNMP
The TLS transport model standard covers SNMP over TLS and DTLS, and it registers separate ports for them. These differ from the classic pair, so a firewall rule for the older ports will not cover them.
| Keyword | Port | Use |
|---|---|---|
| snmptls | 10161/tcp | SNMP-TLS |
| snmpdtls | 10161/udp | SNMP-DTLS |
| snmptls-trap | 10162/tcp | SNMP-Trap-TLS |
| snmpdtls-trap | 10162/udp | SNMP-Trap-DTLS |
These keywords and ports are listed in RFC 6353, and registries can change, so check the source before you rely on them.
Do not confuse this with the built-in security of SNMPv3. That version adds authentication and encryption inside the SNMP message, and it normally still uses the standard UDP ports. TLS and DTLS wrap the transport instead.
How ports show up in everyday configuration
Most monitoring tools hide the port until you need it. You usually enter a host name or address, and the tool assumes the standard agent port unless you add a different one.
On the device side, the agent settings often include a listening address and port. Binding the agent to a management interface only is a simple way to keep it off user networks.
On the receiver side, a trap daemon must be able to bind to its port. On many operating systems, ports below the registered range need elevated privileges. Some teams run the receiver on a higher port and redirect traffic to it at the firewall.
- Agent side: set the listening interface, the port and the allowed managers.
- Manager side: set the device address, the port if it is not standard, and the credentials.
- Receiver side: set the listening port, and tell every device where to send traps.
Keeping a short inventory of any non-standard ports saves hours when someone new takes over the monitoring system.
Opening SNMP ports safely
SNMP exposes a lot of device detail, so treat these ports with care. A few habits keep the risk low.
- Allow UDP 161 on a device only from your monitoring servers, never from the whole internet.
- Allow UDP 162 on the trap receiver only from the devices that send to it.
- Use an authenticated and encrypted version of the protocol where your devices support it.
- Replace default community strings and disable write access you do not need.
- Block both ports at the network edge unless you have a specific reason to expose them.
Remember that UDP is connectionless. Many stateful firewalls track replies automatically, but a stateless filter needs rules for return traffic as well.
Troubleshooting a silent SNMP port
When polling fails, the port is only one of several suspects. Work through the checks in order.
- Confirm the agent is enabled and listening on the expected port on the device itself.
- Check that the community string or user credentials match what the device expects.
- Check access lists on the device that restrict which managers may query it.
- Look for firewalls between the manager and the device that drop UDP.
- Remember that an unreachable object may be a view or SNMP OID problem rather than a port problem.
A packet capture on the manager shows whether requests leave and replies return. If requests leave and nothing comes back, look at the device or the path between you.
Datagram size matters less than it used to, but the standard requires a UDP implementation to accept messages of at least 484 octets. Very large replies from big tables are why some tools lower their request size on lossy links.
A quick test from the command line
Net-SNMP style tools let you query a device and show the result. A walk of the system group tells you the agent answers and the credentials are right.
If the walk times out, test the path next. Because UDP gives no handshake, a plain port check cannot tell “open” from “filtered” reliably. A real SNMP query is the better test.
If you do get an answer, the numbers you see are object identifiers. That is a separate topic from ports, and it is the reason a device can answer on the right port yet still hide some data.
Frequently asked questions
Does SNMP use TCP or UDP?
Show answer
SNMP normally uses UDP. RFC 3430 adds an optional TCP mapping, which recommends TCP ports 161 and 162, but UDP remains the required baseline.
Which port do SNMP traps use?
Show answer
Traps and informs are sent to port 162 on the notification receiver. The standard suggests UDP for this.
Can I change the SNMP port?
Show answer
Yes. The standard only suggests ports 161 and 162, so many devices let you pick another. You must then update every manager or trap sender that talks to it.
Which port does SNMP over TLS use?
Show answer
RFC 6353 registers port 10161 for SNMP over TLS and DTLS, and port 10162 for the matching trap traffic.
