> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # snmp-check on Kali: Find SNMP v2c Still Answering After a v3 Migration - URL: https://www.pinglabz.com/snmp-check-snmpv2c-audit/ - Published: 2026-11-14T17:08:30.000Z - Updated: 2026-11-14T17:10:13.000Z - Description: After an SNMPv3 migration, one leftover community still gave snmp-check the IOS version and every interface over v2c and v1. Removing it produced a timeout; SNMPv3 kept answering. - Author: Jaime - Tags: Kali Linux, SNMP, Cisco IOS XE, Network Engineering, Security To check whether SNMPv2c is really gone after a move to SNMPv3, run `snmp-check -v 2c -c ` with the old community string, then run it again without `-v` to test SNMPv1\. If either returns a **System information** block, the community still works. In my home lab, a Cisco IOS XE 17.18.2 router with a working SNMPv3 user still gave its hostname, IOS version and every interface to both v2c and v1 through one leftover community. After `no snmp-server community`, both returned `SNMP request timeout` while an SNMPv3 `snmpget` kept working. ``` snmp-check -v 2c -c 192.0.2.1 ``` This guide covers install and version check, reading each section of the snmp-check report, the IOS XE cleanup, an ACL-only middle step, the SNMPv3 checks that prove management still works, and how snmp-check compares with snmpwalk and nmap. It pairs with [SNMP RW Community Abuse and SNMPv3](https://www.pinglabz.com/snmp-rw-community-abuse-snmpv3/), which shows why a leftover community is worth an audit. ![snmp-check lab topology: Kali auditor and NMS host polling an IOS XE router on UDP 161](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/diagram-snmp-check-v2.png) Kali tests the leftover community from an unapproved source; the NMS host at 198.51.100.10 is the only source the interim ACL permits. ## Lab setup Topology: Kali `192.0.2.10/24` (the auditor) connects to EDGE `192.0.2.1` on GigabitEthernet2\. A second host, `198.51.100.10/24`, sits behind EDGE on GigabitEthernet3 and plays the network management system (NMS) that is allowed to poll. | Component | Version | | ----------------------------------- | ------- | | Cisco IOS XE (Catalyst 8000V) | 17.18.2 | | snmp-check (Kali package snmpcheck) | 1.9 | | net-snmp (snmpwalk, snmpget) | 5.9.5.2 | | nmap | 7.991 | All output below is from that run. Community strings and SNMPv3 passwords are replaced with placeholders, and long `sysDescr` lines are shortened with `...`. ## Step 1: Install snmp-check and the net-snmp tools On Kali, snmp-check is preinstalled. On Debian or Ubuntu, install it with the net-snmp client tools you need for the SNMPv3 half of the audit: ``` sudo apt install snmpcheck snmp snmp-check -i snmpwalk -V ``` ``` snmp-check v1.9 - SNMP enumerator NET-SNMP version: 5.9.5.2 ``` `snmp-check` and `snmpcheck` are the same tool. It only speaks SNMPv1 and SNMPv2c, which is exactly why it suits this job: any answer it gets is from a legacy community. ## Step 2: Reproduce the half-finished migration on IOS XE This is the state many networks are in after an SNMPv3 rollout: a v3 group and user are configured, and the old read-only community was never removed. ``` configure terminal snmp-server view V3VIEW iso included snmp-server group LABV3 v3 priv read V3VIEW snmp-server user LABV3 v3 auth sha priv aes 128 snmp-server community RO snmp-server location PingLabz home lab snmp-server contact noc@example.net end ``` IOS XE 17.18 warns on both the community and the ACL-less user: ``` SECURITY WARNING - Module: SNMP, Command: snmp-server community * ro , Reason: Legacy protocol poses data confidentiality and integrity risks ... SECURITY WARNING - Module: SNMP, Command: snmp-server user LABV3 v3 auth sha * priv aes 128 *, Reason: SNMP user without ACL ... ``` `show snmp group` tells you more than `show snmp community`. One `snmp-server community` line created two groups, one for `v1` and one for `v2c`: ``` EDGE# show snmp group groupname: LABV3 security model:v3 priv groupname: security model:v1 groupname: security model:v2c ``` The ILMI groups that also appear are platform defaults, not something you configured. ## Step 3: Run snmp-check with the old community ![snmp-check over SNMPv2c lists hostname, IOS XE 17.18.2 and interfaces through the leftover community](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/snmpcheck-v2c-before.png) snmp-check over SNMPv2c lists hostname, IOS XE 17.18.2 and interfaces through the leftover community ## Step 4: Read the snmp-check report snmp-check walks a fixed set of MIB tables and prints one section per table. On this IOS XE router the full report had seven sections after the connection line. | Section | What it showed on IOS XE | Why it matters in an audit | | ---------------------------------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------- | | \[+\] Try to connect ... using SNMPv2c and community | The version and string used | Proves which credential worked | | System information | Hostname EDGE.example.net, full IOS XE version, contact, location, uptime | Software version is enough to look up vulnerabilities | | Network information | IP forwarding yes, TTL 255, TCP and IP counters | Confirms a router, not a host | | Network interfaces | Name, up/down, MAC, speed, MTU, octet counters | Full interface inventory | | Network IP | Every interface address and mask | Includes addresses you may not publish anywhere else | | TCP connections and listening ports | Live TCP sessions | Shows management sessions to the box | | Listening UDP ports | 192.0.2.1:161 and others | Confirms what the box listens on | | File system information | noSuchObject | That MIB is not populated on this platform | Some fields read oddly but are normal: - **Uptime snmp: noSuchObject** over v2c and `-` over v1 mean the same thing: the object is not available. SNMPv2c returns a `noSuchObject` exception, SNMPv1 returns an error, and snmp-check prints each differently. - **Uptime system** is `sysUpTime`, which was 3 minutes 51 seconds here because the router had just booted. - **Speed: 4294 Mbps** on `Null0` and `VoIP-Null0` is the 32-bit `ifSpeed` maximum, not a real rate. The decisive line for this audit is the first `[*] System information:` header. Once you see it, the community works and the rest is detail. ## Step 5: Test SNMPv1 too snmp-check defaults to SNMPv1 when you leave out `-v`. Run it that way as well, because removing "v2c" from an NMS template does nothing about v1 on the device: ![snmp-check over SNMPv1 also answers, and show snmp group shows v1 and v2c groups for the same community](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/snmpcheck-v1-also-answers.png) snmp-check over SNMPv1 also answers, and show snmp group shows v1 and v2c groups for the same community The `-d` flag skips TCP connection enumeration, which keeps the report short when you only need a yes or no. ## Step 6: Restrict by source while you migrate the NMS If an old poller still needs the community for a few days, tie the community to an ACL first. The NMS keeps working and everything else is refused: ``` configure terminal ip access-list standard SNMP-NMS permit 198.51.100.10 deny any log exit snmp-server community RO SNMP-NMS end ``` ![Kali times out, the permitted NMS host still gets data, and the ACL deny counter and SEC-6 log show the refused request](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/snmp-acl-restrict.png) Kali times out, the permitted NMS host still gets data, and the ACL deny counter and SEC-6 log show the refused request Kali got `SNMP request timeout`, the NMS host at `198.51.100.10` still received system information, and EDGE logged `%SEC-6-IPACCESSLOGS: list SNMP-NMS denied 192.0.2.10 1 packet`. The ACL is a stopgap. The community still travels in clear text from the NMS. ## Step 7: Remove the community and re-run ``` configure terminal no snmp-server community end ``` ``` EDGE# show snmp group | include groupname groupname: ILMI security model:v1 groupname: ILMI security model:v2c groupname: LABV3 security model:v3 priv ``` Only the platform ILMI groups and the v3 group remain. Now both versions time out, from every source: ![After removing the community, snmp-check times out over SNMPv2c from the NMS host and over SNMPv1 from Kali](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/snmpcheck-after-timeout.png) After removing the community, snmp-check times out over SNMPv2c from the NMS host and over SNMPv1 from Kali ## Step 8: Prove SNMPv3 still works A timeout from snmp-check says nothing about v3, so finish the audit with an authPriv request: ``` snmpget -v3 -l authPriv -u -a SHA -A -x AES -X \ -m SNMPv2-MIB 192.0.2.1 sysName.0 sysDescr.0 ``` ![SNMPv3 authPriv snmpget returns sysName and sysDescr, followed by the three SNMPv3 errors](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/snmpv3-ok-and-errors.png) SNMPv3 authPriv snmpget returns sysName and sysDescr, followed by the three SNMPv3 errors The three failures in the screenshot are the ones you will hit while fixing NMS templates: | Error | Cause in this lab | | --------------------------------------------------------------------- | -------------------------------------------------------------- | | Authentication failure (incorrect password, community or key) | Wrong auth password | | Error in packet ... authorizationError (access denied to that object) | Right user, but \-l noAuthNoPriv while the group requires priv | | Unknown user name | User not configured on the device | The [Zabbix SNMPv3 article](https://www.pinglabz.com/zabbix-cisco-ios-xe-snmpv3/) shows how the same errors look from a monitoring system. ## snmp-check options reference These are all of snmp-check 1.9's options. | Option | What it does | Default | | -------------------- | ------------------------------- | ------- | | \-c, \--community | Community string | public | | \-v, \--version | SNMP version, 1 or 2c | 1 | | \-p, \--port | UDP port | 161 | | \-t, \--timeout | Seconds to wait per request | 5 | | \-r, \--retries | Retries per request | 1 | | \-d, \--disable\_tcp | Skip TCP connection enumeration | off | | \-w, \--write | Separate check for write access | off | | \-i, \--info | Print the version | | There is no SNMPv3 option and no target-file option. To audit a list, loop in the shell: ``` for host in $(cat devices.txt); do snmp-check -v 2c -c -d "$host"; done ``` ## snmp-check vs snmpwalk vs nmap | | snmp-check 1.9 | snmpwalk / snmpget (net-snmp) | nmap \-sU -p 161 --script snmp-info | | --------------- | ---------------------------------------------------- | --------------------------------- | ------------------------------------- | | SNMP versions | v1, v2c | v1, v2c, v3 | Unauthenticated v3 engine discovery | | Output | Readable report by section | Raw OIDs or MIB names | Engine ID, vendor, boots, engine time | | Needs MIB files | No | For names, yes | No | | Best for | "Does this community work, and what does it expose?" | Checking specific OIDs and SNMPv3 | "Is SNMP listening at all?" | The nmap result after the cleanup is the one people misread: ``` kali@lab:~$ nmap -sU -p 161 --script snmp-info 192.0.2.1 PORT STATE SERVICE 161/udp open snmp | snmp-info: | enterprise: ciscoSystems | engineIDFormat: mac | snmpEngineBoots: 2 ``` UDP/161 is `open` because SNMPv3 is still running and answers engine discovery without credentials. An open port does not mean v2c is enabled. Only a community test answers that. snmpwalk has its own trap on a fresh Kali install: MIB names are not loaded by default. ![snmpwalk fails with Unknown Object Identifier until the MIB is named with -m SNMPv2-MIB](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/snmpwalk-mib-fix.png) snmpwalk fails with Unknown Object Identifier until the MIB is named with -m SNMPv2-MIB Use `-m SNMPv2-MIB` (or `-m ALL`), or use numeric OIDs such as `1.3.6.1.2.1.1.5.0` for `sysName.0`. ## Gotchas **A timeout looks the same for every cause.** A wrong community, an ACL drop and a removed community all produce `[!] 192.0.2.1:161 SNMP request timeout`. The device tells them apart. After the `public` test, `show snmp` showed `2 Unknown community name` (one request plus one retry). The ACL case shows up as `deny any log (2 matches)` and a `%SEC-6-IPACCESSLOGS` line instead. **Ten seconds per failed host.** The `public` test took 10.5 seconds: a 5-second timeout and one retry. For a long device list, lower `-t` and `-r`, or the loop will take a long time. **Testing \`public\` is a false pass.** Use the real string from the old NMS or config archive. A timeout on `public` proves nothing about the community you migrated away from. **\`-w\` is a different action.** It checks whether the community can write. Run it only on your own lab gear or with explicit approval. This audit used read-only checks. **Do not publish the raw report.** The Network IP and TCP connections sections list every interface address and live management session. Trim them before you paste a report into a ticket. ## FAQ ### What is the difference between snmp-check and snmpwalk? snmp-check runs a fixed set of walks and prints a readable report, using SNMPv1 or v2c only. snmpwalk walks any OID tree you give it and supports SNMPv3\. Use snmp-check to find out whether a community works and snmpwalk or snmpget to check specific values over v3. ### Does snmp-check support SNMPv3? No. Version 1.9 accepts only `1` and `2c` for `-v`. That is useful for this audit, because any answer must come from a legacy community. ### Why does snmp-check say SNMP request timeout? Nothing answered that version and community within the timeout. The community may be wrong or removed, an ACL may be dropping your source, or UDP/161 may be filtered on the path. Check `show snmp` counters and ACL matches on the device to find out which. ### How do I know whether SNMPv1 is still enabled on a Cisco router? Run `snmp-check -c ` without `-v`, which uses SNMPv1, and look at `show snmp group`. Each community appears with both `security model:v1` and `security model:v2c`. ### Is UDP port 161 still open after removing all communities? Yes, if SNMPv3 is configured. nmap reported `161/udp open` and read the engine ID with no credentials. Only a community test shows whether v1 or v2c still answer. ### Is it safe to run snmp-check against production devices? Read-only walks are light, but the report is long and each device is walked table by table. Use the `-d` flag, run it from an approved management host, and keep `-w` out of production unless that is the approved test. Scope: this lab covered SNMP on one IOS XE router. Switches and other vendors may add their own default communities, so audit each platform. ## Key takeaways - One `snmp-server community` line enables SNMPv1 and SNMPv2c. Test both with snmp-check: `-v 2c` and the default v1. - A leftover community gave out the hostname, IOS version, interfaces and addresses even though SNMPv3 was already working. - `no snmp-server community` turned both into a timeout. Confirm v3 afterward with an authPriv `snmpget`, and expect UDP/161 to stay open. - snmp-check finds a working community. Use snmpwalk or snmpget for SNMPv3 and specific OIDs, and the device counters to explain a timeout. **More in this series:** [sslscan](https://www.pinglabz.com/sslscan-tls-cipher-check/) to check leftover TLS versions after a hardening pass, [ike-scan](https://www.pinglabz.com/ike-scan-ipsec-vpn-peer/) to test an IPsec VPN peer, and [How to Use masscan](https://www.pinglabz.com/masscan-commands-examples/) when you need to find which hosts still have UDP/161 open. **Series hub:** [Linux Networking Commands: The Complete Guide](https://www.pinglabz.com/linux-networking-commands/) ## Related - [SNMP RW Community Abuse on IOS XE and the SNMPv3 Fix](https://www.pinglabz.com/snmp-rw-community-abuse-snmpv3/) - [SNMP Explained: v2c vs v3, OIDs, MIBs, and Real Polling](https://www.pinglabz.com/snmp-explained/) - [SNMPv3 in Production: Users, Groups, Views, Traps, and Informs](https://www.pinglabz.com/snmpv3-traps-informs/) - [Cisco IOS XE in Zabbix over SNMPv3](https://www.pinglabz.com/zabbix-cisco-ios-xe-snmpv3/) - [Hardening the Management Plane on Cisco IOS XE](https://www.pinglabz.com/hardening-management-plane-ios-xe/) - [nmap](https://www.pinglabz.com/nmap/)