How to Change the SNMP Port (and When to)

By the SNMP Monitoring team · Reviewed July 2026

SNMP listens on UDP 161 by default, and most of the time you should leave it there. But people do move it — to sidestep noisy internet-wide scans, to run two agents on one host, or to fit a policy that reserves 161 for something else. Changing the port is a one-line edit in snmpd.conf, but it comes with a caveat worth stating up front: a non-standard port is obscurity, not security. This guide shows the edit, the firewall and manager changes it forces, and what actually hardens an agent instead.

Parent: setup. Background: SNMP ports.

Obscurity ≠ security

Be clear-eyed about what a port change buys you. It moves the agent off the address every mass scanner hits first, so your logs get quieter — but a targeted attacker runs a port sweep and finds it in seconds. What changing the port does and doesn't do:

• Does: reduce background noise from bots that only probe 161.
• Does: avoid a port collision when two services want the same number.
• Doesn't: stop anyone who scans your host's full port range.
• Doesn't: encrypt anything or authenticate anyone — a v2c community on port 16100 is still cleartext.
• Doesn't: replace a source-IP ACL, an OID allowlist, or SNMPv3.

Treat a custom port as tidying, not defence. The real controls come later on this page.

Step 1: Edit agentAddress

The listening port is set by the agentAddress directive in /etc/snmp/snmpd.conf. To move the agent to UDP 16100:

agentAddress udp:16100

To do it cleanly:

1. Open /etc/snmp/snmpd.conf.
2. Set agentAddress udp:16100 (add the management IP too — udp:10.0.0.20:16100 — to bind one interface).
3. Restart with sudo systemctl restart snmpd.
4. Confirm the new socket is listening: sudo ss -lunp | grep 16100.

UNCONN 0 0 10.0.0.20:16100 0.0.0.0:* users:(("snmpd",pid=1423,fd=8))

A line showing snmpd bound to :16100 means the change took. If snmpd won't start, re-check the directive syntax — a malformed agentAddress stops the daemon.

Step 2: Update the firewall

The agent is now deaf on 161 and listening on 16100, so your firewall must follow. Open the new port to your manager and close the old one — see firewall setup for the full rules. For ufw:

sudo ufw allow from 10.0.0.5 to any port 16100 proto udp
sudo ufw delete allow 161/udp

Leaving 161 open after the move is pure attack surface with nothing behind it, so remove it. Scope the new rule to the manager's source IP, exactly as you would for 161 — the port number changed, the least-exposure principle didn't.

Step 3: Update managers and pollers

Every manager must now target the new port explicitly, or it'll keep hammering a closed 161 and time out. In net-snmp, append :<port> to the host:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20:16100 system

Update your monitoring platform's device config the same way — most expose a "port" field next to the host. Miss one poller and it simply goes dark on that device, which is an easy incident to misdiagnose, so change them all in the same maintenance window.

Step 4: Verify old vs new

Prove both halves of the move: the new port answers, the old one doesn't. New port:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20:16100 system

SNMPv2-MIB::sysDescr.0 = STRING: Linux app02 5.15.0-generic x86_64
SNMPv2-MIB::sysUpTime.0 = Timeticks: (23456789) 2 days, 17:09:27.89

Old port, which should now fail:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 system

Timeout: No Response from 10.0.0.20

Data on 16100 and a timeout on the default port confirms the agent moved cleanly and nothing is still exposed on 161.

Better hardening than a port change

If your goal was security, a port change is the weakest lever available. These actually protect the agent:

Do the top three and the port number barely matters. A note on the standardised transports: TLS/DTLS SNMP uses 10161/10162, which are assigned ports for an encrypted transport — don't confuse picking an arbitrary UDP port like 16100 with moving to those. More at SNMP hardening.

Caveats

Two things people forget. First, traps: if you also relocate trap traffic, the receiver listens on 162 by default and both the trap2sink/trapsink line and the receiver must agree on the new port. Second, multiple agents: running two snmpd instances on one host is a legitimate reason to use a non-standard port, but each needs its own agentAddress, config file, and persistent-state directory, or they'll clash on startup.

There's also a documentation cost that's easy to underestimate. The moment your agent stops listening on 161, you've created a small piece of tribal knowledge that has to live somewhere other than in one engineer's head. Six months later, someone doing an ad-hoc snmpwalk against the box will get a timeout, assume the agent is broken, and burn time before they discover it simply moved. Record the custom port in your CMDB or device inventory alongside the host, so the next person doesn't rediscover it the hard way. If you run a fleet, standardise on one alternate port rather than a different number per host — inconsistency is worse than either the default or a single well-known custom value, because it turns every check into a guessing game.

Frequently asked questions

How do I change the SNMP port?

Edit agentAddress in /etc/snmp/snmpd.conf — e.g. agentAddress udp:16100 — then restart snmpd. Update your firewall to open the new port and close 161, and reconfigure every manager to target <host>:<port>. Verify with snmpwalk -v2c -c <string> <host>:16100 system.

Does changing the port improve security?

Only marginally, and only as obscurity. A custom port reduces noise from mass scanners that probe 161, but a targeted attacker finds it with a quick port scan, and the traffic is exactly as exposed as before. Real protection comes from SNMPv3, an OID allowlist, and a source-IP firewall — not the port number.

How do I poll SNMP on a custom port?

Append the port to the host argument: snmpwalk -v2c -c <string> <host>:16100 system (and likewise for snmpget). In a monitoring platform, set the device's SNMP port field to the new value. Every poller must be updated, or it will keep querying 161 and time out.

Do I need to update the firewall after changing the port?

Yes. The agent no longer listens on 161, so open the new port to your manager's source IP and remove the old 161 rule — leaving it open is attack surface with nothing behind it. If you relocate traps too, update the trap port (default 162) on both sender and receiver.

Key takeaways

• The default is UDP 161; change it with agentAddress udp:<port> in snmpd.conf.
• A custom port is obscurity, not security — it quiets scans, nothing more.
• Update the firewall (open new, close 161) and every manager (<host>:<port>).
• Verify both ways: new port answers, old port times out.
• For real protection use SNMPv3, an OID allowlist, and a firewall ACL.
• TLS/DTLS SNMP uses standardised 10161/10162 — don't conflate that with an arbitrary UDP port.