Technical Tip: SNMP walk command returns no output even with all configuration in place

Issue:

Administrators may observe:

• SNMPwalk toward FortiGate fails with a timeout.
• SNMP requests are visible in packet capture.
• FortiGate does not send a reply.
• The same SNMPwalk works against other vendor devices.
• Correct authentication values are provided, but still, no data is returned.

Attempts to troubleshoot authentication or privacy parameters may not resolve the issue because the underlying cause is related to where the walk begins in the OID tree.

Cause:

When the SNMPwalk is initiated using an OID root that does not contain valid MIB objects on the FortiGate (for example, `.1`), the device has no applicable data to return, resulting in 'timeout' or empty responses.

Once the query is issued using a valid subtree such as '.1.3', the FortiGate immediately responds with standard system information and other SNMP data.

Solution:

Start SNMP polling from a valid MIB branch, for example, '.1.3':

Example (SNMPv3):

SnmpWalk -r:<FG_IP> -v:3 -sn:<user> -ap:SHA -aw:<auth_pwd> -pp:AES128 -pw:<priv_pwd> -os:.1.3

Example output:

OID=.1.3.6.1.2.1.1.1.0 ...
OID=.1.3.6.1.2.1.1.5.0 ...

Alternative valid starting points:

`.1.3`
`.1.3.6`
`.1.3.6.1.2.1`

Use case scenario:

When performing SNMPwalk tests toward FortiGate using only '.1', it returned a timeout and no system information.

However, when the same SNMPwalk was executed using '.1.3', the device returned expected values (system description, uptime, hostname).

The issue was resolved by adjusting the starting OID, without any configuration changes on the FortiGate.

Additional notes:

• This behavior can affect SNMPv1/v2c/v3.
• Debug messages related to authentication or USM errors may appear, but do not necessarily indicate a configuration problem in this scenario.
• If responses are still not received after using a correct OID, verify the auth/priv settings and supported algorithms.

Summary:

Even when SNMP is reachable and configured correctly, FortiGate may not return data if polling begins at an incorrect OID root. Starting the SNMPwalk from a valid MIB subtree, such as '.1.3', resolves the issue and allows the FortiGate to respond normally.