---
type: Article
title: "Change the SNMP Port"
description: "Move the SNMP agent off UDP 161 — the first port every scanner checks — in a single snmpd.conf line, plus the firewall rule and how to query the new port."
resource: "https://snmp-monitoring.com/setup/custom-port/"
tags: [setup, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# Change the SNMP Port

You can change the SNMP port in a single line, and on any internet-facing agent you probably should. By default the SNMP agent listens on UDP 161 — a number every port scanner on earth checks first. Moving the service to a non-default SNMP port won't make a weak configuration strong, but it does make your agent invisible to the automated sweeps that trawl 161 all day looking for open communities. It's cheap, it's fast, and it pairs neatly with the other hardening steps. This guide covers the one-line change in `snmpd.conf`, the firewall rule that has to follow it, and how to query the moved agent so your monitoring doesn't break in the process.

## Prerequisites

Before you touch the port, get these in order:

- **A working SNMP agent on UDP 161** — if it isn't running yet, start at [Install snmpd on Ubuntu/Debian](/setup/install-snmpd-ubuntu-debian.md).
- **Root or sudo** to edit `/etc/snmp/snmpd.conf` and manage the firewall.
- **A chosen port number.** Pick something high and unremarkable in the 1024–65535 range, and check it doesn't clash with another service (`ss -lnu` shows what's already listening on UDP).
- **Firewall access** — `ufw`, `firewalld`, `iptables`, or a cloud security group — because moving the listener without moving the firewall rule just breaks polling.
- **A test client** with `snmpwalk` to confirm the agent answers on its new home.

Also warn anyone or anything that already polls this host. Every poller, script, and monitoring endpoint pointed at `:161` needs updating, or it'll start timing out the moment you restart.

![Screenshot: editing the agentAddress line in snmpd.conf to move the SNMP agent off port 161 to a custom UDP port](https://snmp-monitoring.com/img/setup/change-snmp-port.webp)

## Step-by-step

The move itself is trivial; the follow-through is what people miss. Do all five.

1. **Open the config:**
   ```bash
   sudo nano /etc/snmp/snmpd.conf
   ```
2. **Edit the `agentAddress` line** to your chosen port — here, 16161:
   ```bash
   agentAddress udp:16161,udp6:[::1]:16161
   ```
   That single directive is the whole port change. Everything else in the file — community, groups, views — stays exactly as it was.
3. **Restart the agent** so it rebinds:
   ```bash
   sudo service snmpd restart
   ```
4. **Open the new port in the firewall** and, ideally, close the old one. With `ufw`:
   ```bash
   sudo ufw allow from 10.20.0.0/24 to any port 16161 proto udp
   sudo ufw delete allow 161/udp
   ```
   Scope the rule to your poller's subnet rather than opening the port to the world — a moved port plus a tight source is far stronger than either alone.
5. **Update every client** that polls this host to include the new port, and confirm nothing is still hammering 161.

There's one subtlety worth naming. SNMP runs over UDP, so a firewall that silently drops packets to the old port produces a *timeout*, not a refusal — which looks identical to a dead agent. When you test, a hang almost always means a firewall or client still stuck on 161, not a broken daemon. Keep that in mind and the debugging goes quickly.

## Configuration example

The default vs a hardened port choice:

| Aspect | Default | Hardened |
|---|---|---|
| Agent port | UDP 161 | random high UDP port |
| Config line | `agentAddress udp:161` | `agentAddress udp:<port>` |
| Trap port | UDP 162 | unchanged unless used |
| ostr.io endpoint | enter `161` | enter the chosen port |


The change lives on one line. Here it is in context with a comment marking the before-and-after:

```bash
# /etc/snmp/snmpd.conf  (excerpt)

# Default (scanned constantly):
# agentAddress udp:161,udp6:[::1]:161

# Custom non-default port:
agentAddress udp:16161,udp6:[::1]:16161
```

And the matching firewall rules, scoped to a monitoring subnet:

```bash
# Allow only the poller subnet to reach the new UDP port
sudo ufw allow from 10.20.0.0/24 to any port 16161 proto udp
# Remove the stale rule for the old port
sudo ufw delete allow 161/udp
```

Notice what didn't change: the `com2sec`, `group`, `view`, and `access` directives are untouched. Moving the port is purely a listener change — it doesn't alter who may read which OIDs, and it isn't a substitute for a strong community. The default of 161 is registered to SNMP for a reason, so document your custom port somewhere your team will find it; an undocumented port is a support ticket waiting to happen. The full ACL those other directives control is covered on the [snmpd.conf page](/setup/snmpd-conf.md).

## Verify it works

Restart, then prove the agent answers on the new port and confirm the old one is closed.

```bash
service snmpd status
```

From your test machine, walk host uptime, appending the new port to the host with a colon:

```bash
snmpwalk -v2c -c <community> <host>:16161 1.3.6.1.2.1.25.1.1.0
```

A returned `hrSystemUptime` value means the moved agent is reachable and your firewall rule is correct. Then confirm 161 no longer answers:

```bash
snmpwalk -v2c -c <community> <host>:161 1.3.6.1.2.1.25.1.1.0
```

A timeout here is the result you want — it means nothing is listening on the old, heavily scanned port anymore. Remember the colon-port syntax (`<host>:16161`); leaving it off sends the query to 161 by default and produces a confusing hang that has nothing to do with your config.

## Security note

A non-default port is obscurity, not security — useful, but only as one layer. Stack it with the rest:

- **Don't rely on the port alone.** Keep a [strong random community string](/setup/secure-community-string.md); a moved port with `public` is still trivially owned once found.
- **Scope the firewall** to known pollers, so even a discovered port refuses strangers.
- **Prefer high, unremarkable ports** over near-161 numbers like 162 (that's the trap port) or 1161.
- **Keep access read-only** in the config — moving ports changes nothing about write protection.
- **Log and review** what still probes the old port; it tells you who hadn't got the memo.
- **See the broader model** on the [security overview](/security/index.md).

Obscurity buys you quiet. Real protection still comes from the community, the source restriction, and read-only access working together.

## Next: connect external monitoring

Changing the port has a practical knock-on effect: any external monitor needs to know the new number too. That's a feature, not a nuisance — it means only endpoints you've explicitly configured can reach the agent. And you'll want an external endpoint, because the alerts that matter are the ones that arrive when the server itself has gone quiet. Polling from outside your network is what makes that possible, the core idea behind [double durability](/monitoring/double-durability.md): an independent watcher keeps checking straight through the failures that mute on-host tools.

[ostr.io Monitoring](https://ostr.io/service/monitoring) lets you specify the exact SNMP port when you register a server, so your custom port is just a field in the setup — it then polls from outside your infrastructure and fires real-time email and SMS alerts on any threshold breach. The [add-endpoint guide](/setup/add-endpoint-ostrio.md) shows where the port goes.

![Diagram: a port scanner sweeping UDP 161 and missing an SNMP agent relocated to a non-default port behind a scoped firewall](https://snmp-monitoring.com/img/setup/non-default-snmp-port.webp)

## FAQ

**What is the default SNMP port, and why change it?**
The agent listens on UDP 161 by default (traps use 162). It's changed to cut exposure to automated scanners that constantly probe 161 for open communities — a non-default port makes those bulk sweeps miss you.

**Does changing the SNMP port actually improve security?**
It reduces noise and drive-by discovery, but it's obscurity, not a real control. Treat it as one layer on top of a strong community string, a scoped firewall, and read-only access — never as a replacement for them.

**How do I query an agent on a non-default port?**
Append the port to the host with a colon: `snmpwalk -v2c -c <community> <host>:16161 <oid>`. Leave the colon-port off and the client defaults back to 161.

**Do I have to change the firewall too?**
Yes, and it's the step people skip. Open the new UDP port to your pollers and remove the old 161 rule. Because SNMP is UDP, a missed firewall rule shows up as a silent timeout, not an error.

## Conclusion

To change the SNMP port, you edit one `agentAddress` line, restart, and update the firewall and every client to match — moving the agent off the endlessly scanned UDP 161 to a quiet non-default SNMP port. It's obscurity that buys you real peace from bulk scanning, but only when it sits on top of a strong community and a scoped firewall. Set the port, verify the agent answers there and nowhere on 161, then point an external checker at the new endpoint so your monitoring keeps watching through the outages the server can't report itself.