SNMP Requests Arrive but No Response Is Sent

Seeing an inbound UDP/161 packet in tcpdump does not prove that the SNMP agent received or accepted it. The host firewall can still drop the packet, snmpd can be bound to another address, an access rule can reject the real source, or the reply can leave through the wrong route. Trace one request across those boundaries.

Create a bounded client test

snmpget -v2c -c "$COMMUNITY" -t 2 -r 0 \
  192.0.2.10 1.3.6.1.2.1.1.3.0

Use a numeric scalar OID before running a full walk. This avoids mixing MIB loading problems with transport failures. The two-second timeout and zero retries create one request that is easy to match in a capture.

sudo tcpdump -ni any 'udp port 161 and host 192.0.2.50'

If the request is visible but there is no packet from server port 161 back to the client, stay on the server. If a reply leaves the server but never reaches the client, inspect the return path and intermediate policy.

Verify the socket, not just the service state

sudo systemctl status snmpd --no-pager
sudo ss -lunp | grep ':161'
sudo journalctl -u snmpd --since '-15 min' --no-pager

UNCONN 0 0 127.0.0.1:161 0.0.0.0:* users:(("snmpd",pid=812,fd=6))

This socket accepts only local IPv4 traffic. Net-SNMP’s agentAddress directive controls listening endpoints:

agentAddress udp:161

Binding a specific management address is safer on a multi-homed host, but that address must be the one reached by the monitoring system.

Compare loopback and remote behavior

snmpget -v2c -c "$COMMUNITY" -t 2 -r 0 \
  127.0.0.1 1.3.6.1.2.1.1.3.0

If loopback also times out, investigate the agent, listener and authentication configuration before the network. If loopback works while the remote query fails, prioritize the bind address, source-based access rule and host firewall.

Match access control against the source seen on the wire

rocommunity monitor_ro 192.0.2.0/24

The optional source field in rocommunity COMMUNITY SOURCE restricts which client addresses may use that community. A NAT gateway can make the agent see a different source from the monitoring node’s configured address. Use the packet capture source, not an inventory assumption.

Avoid exposing real community strings in shell history, screenshots or incident tickets. Use a temporary diagnostic credential where possible and rotate it if it has been disclosed.

For SNMPv3, verify the entire security profile

snmpget -v3 -l authPriv -u monitor \
  -a SHA -A "$AUTH_PASS" -x AES -X "$PRIV_PASS" \
  -t 2 -r 0 192.0.2.10 1.3.6.1.2.1.1.3.0

The user, security level, authentication and privacy algorithms must match. Engine-ID discovery and time-window errors can also prevent a useful response. RFC 3414 defines counters including usmStatsUnknownUserNames, usmStatsUnknownEngineIDs, usmStatsNotInTimeWindows and usmStatsWrongDigests. Reading those counters through a known-good administrative path can identify the failing layer.

A packet capture can precede the firewall decision

sudo nft list ruleset
sudo iptables -L INPUT -n -v

Compare the relevant rule counter before and after the single request. Capturing a packet on any is compatible with it being dropped later by netfilter. Avoid adding a permanent any-source UDP/161 allow rule as a diagnostic shortcut; limit any temporary rule to the monitoring source.

Prove the return route

ip route get 192.0.2.50 from 192.0.2.10
ip rule show
ip route show table all
sysctl net.ipv4.conf.all.rp_filter

A multi-homed server may receive the request on one interface and select another source address or gateway for the reply. Policy routing and reverse-path filtering can turn this into a silent timeout even though the service configuration is correct.

Use foreground debug only in a maintenance window

Start with the existing service log:

sudo journalctl -u snmpd -f

A foreground Net-SNMP process cannot share the same UDP socket with the running service. For packet-level agent debug, stop the managed service deliberately and keep a recovery command ready:

sudo systemctl stop snmpd
sudo snmpd -f -Lo -d -c /etc/snmp/snmpd.conf

-f stays in the foreground, -Lo logs to standard output and -d dumps received and sent SNMP packets. End the test, then start and verify the normal service.

Verify one request and one response

snmpget -v2c -c "$COMMUNITY" -t 2 -r 0 \
  192.0.2.10 1.3.6.1.2.1.1.3.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (482193) 1:20:21.93

The basic path is restored when the server capture shows one inbound request and one outbound reply and the client prints the scalar value. If the request still arrives without a reply, return to the listener, the actual source address and the agent’s access rule rather than widening the capture filter.

References: Net-SNMP snmpd.conf, snmpd manual and RFC 3414 USM.