SNMP port numbers: UDP 161, 162, 10161 and 10162 explained

Short answer: SNMP uses UDP port 161 for queries: the monitoring system (the manager) sends its Get and Walk requests to the agent on 161. Traps and informs travel the other way, from the agent to the manager’s UDP port 162. SNMP over TLS or DTLS uses 10161 and 10162. Open 161 to your monitoring host only.

The 161 and 162 assignments come from RFC 3417, the transport mappings for SNMP, and Debian’s /etc/services lists them as snmp and snmp-trap. In practice, “the SNMP port” means UDP 161 on the device you want to read.

Port 161 vs port 162: which way does the traffic go?

SNMP has two roles. The agent runs on the thing being watched (a server, a switch, a printer) and answers questions about it. The manager is the monitoring system that asks those questions and collects alerts. Each listens on its own port:

manager (monitoring host)                  agent (your server)
198.51.100.20                              203.0.113.10

any port  ---- GetRequest / GetBulk ---->  UDP 161 (snmpd)
any port  <--- Response ----------------   UDP 161

UDP 162   <--- Trap or Inform ----------   any port
(snmptrapd)
UDP 162   ---- Response (ack) --------->   any port (informs only)

• On the server you monitor: allow UDP 161 in, from the monitoring host only. The replies go back automatically, because ufw and firewalld track the request.
• On the monitoring host: allow UDP 162 in from your servers, and only if you want traps. Polling needs no inbound rule there.
• Traps vs informs: a trap is fire and forget, so it is lost if the packet is. An inform asks the manager for an acknowledgement and is resent until it gets one.

What are ports 10161 and 10162?

RFC 6353 lets SNMP run inside TLS (over TCP) or DTLS (over UDP) and authenticate with certificates instead of SNMP’s own users. It got its own ports: 10161 for agents and 10162 for notifications. Support depends on how the agent and your monitoring software were built, and few setups use it; SNMPv3 with authentication and encryption over UDP 161 is the common choice.

SNMP versions: v1, v2c and v3

A community string is a password that every request carries unencrypted, and the well-known defaults are public (read) and private (write). SNMPv3 replaces it with the User-based Security Model (RFC 3414): each user has an authentication passphrase that signs every message and a privacy passphrase that encrypts it. Of the three security levels, noAuthNoPriv, authNoPriv and authPriv, use authPriv.

Should port 161 be open to the internet?

No. The common ports list files 161 and 162 under “never, or allowlist your monitoring host”, for three reasons:

• Amplification attacks. SNMP runs over UDP, which does not check who is asking. An attacker sends a small GetBulk request with the victim’s address forged as the sender, and your agent sends a much larger answer to the victim. CISA’s alert on UDP-based amplification lists SNMPv2 with a bandwidth factor of 6.3. How this works, and why it ends in DDoS traffic, is the same as for open DNS resolvers.
• Information leaks. With a guessable community, anyone can read your hostname, interfaces, routes, running processes and, depending on the view, the list of installed software.
• Guessing is cheap. Over UDP a scanner can try thousands of community strings in seconds, and a v1 or v2c agent that drops wrong guesses silently never slows it down.

Internet-wide scanners look for open SNMP agents all the time and report them to the network owner, who forwards the report to you. An agent abused for reflection makes your server part of someone else’s DDoS. VMHeaven’s acceptable use policy makes the customer responsible for all software installed on the server, an open snmpd included, and the terms name DDoS attacks among the reasons a service can be suspended.

Check whether snmpd is running and where it listens

sudo apt install snmpd snmp      # agent + command-line tools
sudo ss -ulnp | grep snmpd

sudo dnf install net-snmp net-snmp-utils
sudo systemctl enable --now snmpd
sudo ss -ulnp | grep snmpd

UNCONN 0      0          127.0.0.1:161        0.0.0.0:*    users:(("snmpd",pid=902,fd=6))
UNCONN 0      0              [::1]:161           [::]:*    users:(("snmpd",pid=902,fd=7))

Debian 12 ships net-snmp 5.9.3. Its packaged /etc/snmp/snmpd.conf binds the agent to 127.0.0.1 and ::1 (the agentaddress line) and lets the community public read only a small view: the system group and a few host values such as uptime. Ubuntu uses the same file. The stock configuration on Rocky and AlmaLinux has no agentaddress line, which means UDP 161 on every IPv4 address, and only firewalld keeps it closed. If ss shows 0.0.0.0:161 or *:161, the agent is reachable on every address and your firewall is the only thing in the way. If sudo ss -tlnp also shows snmpd on TCP 199 at 127.0.0.1, that is SMUX, and it stays local.

Query your own agent with snmpget and snmpwalk

snmpwalk -v2c -c public localhost .1.3.6.1.2.1.1      # the system group
snmpget  -v2c -c public localhost .1.3.6.1.2.1.1.5.0  # just the host name

iso.3.6.1.2.1.1.1.0 = STRING: "Linux vps1 6.1.0-40-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.153-1 x86_64"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
iso.3.6.1.2.1.1.3.0 = Timeticks: (8640123) 1 day, 0:00:01.23
iso.3.6.1.2.1.1.4.0 = STRING: "Me <me@example.org>"
iso.3.6.1.2.1.1.5.0 = STRING: "vps1"
iso.3.6.1.2.1.1.6.0 = STRING: "Sitting on the Dock of the Bay"
iso.3.6.1.2.1.1.7.0 = INTEGER: 72
...

The contact and location lines are the placeholders from Debian’s sample file; set your own with sysContact and sysLocation. The numbers instead of names are also normal on Debian and Ubuntu: the packages leave out most MIB files for licence reasons, and /etc/snmp/snmp.conf turns MIB loading off with a mibs : line. Install snmp-mibs-downloader (Debian non-free, Ubuntu multiverse) and comment out that line, and the same walk prints SNMPv2-MIB::sysName.0 = STRING: vps1. Numeric OIDs work either way, so these are the ones worth knowing:

With the packaged view, most of these answer No Such Object available on this agent at this OID: the agent has the data but the community may not read it. Widening the view is part of the setup below.

Set up snmpd for one monitoring host

The goal: the agent answers your monitoring host over SNMPv3 with encryption, and nobody else. The file is /etc/snmp/snmpd.conf on Debian, Ubuntu and Rocky.

1. 1Choose the addresses snmpd listens on

   # replace the existing agentaddress line:
   # the server's public address and localhost, nothing else
   agentaddress  udp:203.0.113.10:161,udp:127.0.0.1:161

2. 2Define what may be read, and drop the public community

   # MIB-2 (system, interfaces, host resources), then net-snmp's load, memory and disks
   view   monitored  included  .1.3.6.1.2.1
   view   monitored  included  .1.3.6.1.4.1.2021
   disk   /
   
   # replace the packaged sysLocation and sysContact lines:
   sysLocation  Amsterdam
   sysContact   ops@example.com
   
   # comment out the packaged rocommunity / rocommunity6 lines for "public"

   Keep comments on lines of their own: snmpd may read text after a directive as more arguments.

3. 3Create an SNMPv3 user

   sudo systemctl stop snmpd
   echo 'createUser monitor SHA-256 "first-long-passphrase" AES "second-long-passphrase"' \
     | sudo tee -a /var/lib/snmp/snmpd.conf
   echo 'rouser monitor priv -V monitored' | sudo tee -a /etc/snmp/snmpd.conf
   sudo systemctl start snmpd

   The createUser line goes into snmpd’s persistent file (on Rocky, /var/lib/net-snmp/snmpd.conf), and only while snmpd is stopped. At start the agent turns it into keys and removes the clear-text line, as the snmpd.conf man page describes. Both passphrases need at least 8 characters. SHA-256 needs net-snmp 5.8 or newer and a monitoring tool that offers it; if yours only knows SHA, use SHA here too.

4. 4Test locally

   snmpget -v3 -l authPriv -u monitor -a SHA-256 -A 'first-long-passphrase' \
     -x AES -X 'second-long-passphrase' localhost .1.3.6.1.4.1.2021.10.1.3.1

   iso.3.6.1.4.1.2021.10.1.3.1 = STRING: "0.08"

Passphrases on the command line end up in your shell history. For regular use put defSecurityName, defSecurityLevel, defAuthType, defAuthPassphrase, defPrivType and defPrivPassphrase into ~/.snmp/snmp.conf (mode 600) on the monitoring host, and the tools pick them up.

If your monitoring tool only speaks v2c

# community from: openssl rand -hex 16
rocommunity  3f9c1e7a5b2d48c6a0e1f7b39d4c2a85  198.51.100.20  -V monitored

The source address makes the agent ignore requests from anywhere else, but UDP senders can be forged and the community still crosses the network in clear text, so the firewall rule below is not optional.

Firewall: allow port 161 from the monitoring host only

sudo ufw allow from 198.51.100.20 to any port 161 proto udp
sudo ufw status numbered

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.20/32" port port="161" protocol="udp" accept'
sudo firewall-cmd --reload

Do not add a plain ufw allow 161/udp next to it; that opens the port to everyone. More on scoping rules by source is in the ufw guide. Then test from both sides:

snmpget -v3 -l authPriv -u monitor -a SHA-256 -A '...' -x AES -X '...' 203.0.113.10 .1.3.6.1.2.1.1.5.0
# monitoring host:  iso.3.6.1.2.1.1.5.0 = STRING: "vps1"
# anywhere else:    Timeout: No Response from 203.0.113.10

Online port checkers cannot help here: they test TCP, and UDP has no handshake, so a silent port looks the same as a filtered one. nmap -sU -p 161 usually reports open|filtered for that reason. A real SNMP request is the only reliable test, as checking UDP ports explains.

Receiving traps on port 162

Traps flow to the monitoring host, so this happens there. On Debian 12 the receiver is its own package, snmptrapd:

authCommunity log,execute,net  trap-secret

sudo apt install snmptrapd      # then add the line above
sudo systemctl restart snmptrapd
sudo ufw allow from 203.0.113.10 to any port 162 proto udp

# informsink instead of trap2sink asks for acknowledgements
trap2sink  198.51.100.20  trap-secret

sudo systemctl restart snmpd
snmptrap -v2c -c trap-secret 198.51.100.20 '' .1.3.6.1.6.3.1.1.5.1

The last line sends a coldStart trap. Since net-snmp 5.3, snmptrapd discards every notification for which no authCommunity or authUser line exists, so “the packets arrive but nothing is logged” is almost always that line. Check what came in with journalctl -u snmptrapd.

SNMP errors and what they mean

SNMP on a VPS or dedicated server

SNMP is at its best where a monitoring system already polls switches, firewalls and UPS units and your servers simply join the list. For a handful of Linux servers and nothing else, an HTTP or TCP check from a tool like Uptime Kuma often covers what matters with no agent and no open port at all. Either way, keep the monitoring host away from what it watches: a monitor on the same server, or in the same data centre, goes quiet exactly when you need it. With VMHeaven VPS locations in Amsterdam and Frankfurt, a small monitoring VPS in one city can watch the servers in the other, as the Uptime Kuma guide explains.

Frequently asked