Troubleshooting Tip: No SNMP response from FortiGate due to disabled SNMP sysinfo status

Scenario:

1. SNMP monitoring is performed from a remote SNMP manager.
2. SNMP traffic traverses an IPsec VPN tunnel.
3. SNMP queries are generated using the net-snmp tools.

For testing purposes, SNMPv3 queries were generated using the snmpwalk command.
The net-snmp tool can be downloaded from the following link: Net-SNMP.

Basic syntax for SNMPv3 and SNMPv2 snmpwalk:

snmpwalk -v3 -l authPriv -u snmptest -a SHA -A <password> -x DES -X <password> 3.1.1.4 .1
snmpwalk -v2c -c snmptest 3.1.1.4 .1

Note:
Windows net-snmp tools may have limitations when handling SNMPv3 debugging; only sniffer and debug flow results are verified during troubleshooting. If the same test is performed using SNMPv2, the response may be confirmed normally.

The issue is that even though SNMP request packets reach the FortiGate device, no SNMP response packets are generated. The related logs are shown below.

1. Packet sniffer:

SCMVPN_DA in 15.1.1.10.55102 -> 3.1.1.4.161: udp 36
SCMVPN_DA in 15.1.1.10.55102 -> 3.1.1.4.161: udp 36

SNMP request packets arrive at the FortiGate interface, but no reply packets are observed, indicating that the SNMP queries reach the device, but responses are not generated.

2. SNMPD debug:

snmpd: updating cache: idx_cache

SNMP daemon logs do not show request processing, suggesting that the SNMP daemon does not process the incoming SNMP request.

3. Debug flow:

id=65308 trace_id=168 func=print_pkt_detail line=5872 msg="vd-root:0 received a packet(proto=17, 15.1.1.10:62077->3.1.1.4:161) tun_id=12.1.1.2 fro m SCMVPN_DA. "
id=65308 trace_id=168 func=resolve_ip_tuple_fast line=5960 msg="Find an existing session, id-0000038f, original direction"
id=65308 trace_id=168 func=ipsec_spoofed4 line=241 msg="src ip 15.1.1.10 match selector 0 range 15.1.1.0-15.1.1.255"
id=65308 trace_id=169 func=print_pkt_detail line=5872 msg="vd-root:0 received a packet(proto=17, 15.1.1.10:62077->3.1.1.4:161) tun_id=12.1.1.2 fro m SCMVPN_DA. "
id=65308 trace_id=169 func=resolve_ip_tuple_fast line=5960 msg="Find an existing session, id-0000038f, original direction"

This indicates that the SNMP traffic successfully reaches the FortiGate and a session is created normally, but no SNMP response is generated.

Root cause:

If the SNMP sysinfo status is disabled, the FortiGate device will not respond to SNMP queries even if other SNMP configurations (community, user, host, etc.) are correctly configured.

Solution:

Verify that SNMP system information reporting is enabled.

config system snmp sysinfo
    set status enable
end

After enabling the setting, SNMP responses are generated normally.

1. Packet sniffer:

SCMVPN_DA in 15.1.1.10.52184 -> 3.1.1.4.161: udp 60
SCMVPN_DA out 3.1.1.4.161 -> 15.1.1.10.52184: udp 123

Both request and response packets are observed.

2. SNMPD debug:

snmpd: <msg> 60 bytes 15.1.1.10:52681 -> 3.1.1.4/3.1.1.4:161 (itf 20.20)
snmpd: v3 recv parse: packet (60 left)
snmpd: v3 recv parse: version: 3 (55 left)
snmpd: v3 recv parse: msgGlobalData (38 left)
snmpd: data [(15) (02 02 26 53 02 03 00 ff e3 04 01 04 02 01 03 )(..&S...........)]
snmpd: v3 recv parse: msgFlags: 0x04
snmpd: usm recv parse: packet (38 left)
snmpd: usm recv parse: msgSecurityParameters: sz=16 left=20
snmpd: usm secparams parse: msgSecurityParameters: sz=14 left=0
snmpd: data [(14) (04 00 02 01 00 02 01 00 04 00 04 00 04 00 )(..............)]
snmpd: usm secparams parse: msgUserName: (4 left)
snmpd: usm scopedpdu parse: scoped PDU sz=20
snmpd: data [(20) (30 12 04 00 04 00 a0 0c 02 02 66 89 02 01 00 02 01 00 30 00 )(0.........f.......0.)]
snmpd: usm scopedpdu parse: msgData (0 left)
snmpd: usm scopedpdu parse: msgType: 0xa0 (12 left)
snmpd: usm scopedpdu parse: b_vars: <>(0) (0 left)
snmpd: usm scopedpdu parse: no varbinds.
snmpd: </msg> 1

The SNMP daemon processes the request normally, confirming that the SNMP request is successfully parsed and handled.

3. Debug flow:

id=65308 trace_id=174 func=resolve_ip_tuple_fast line=5960 msg="Find an existing session, id-00000622, reply direction"
id=65308 trace_id=174 func=ip_session_core_in line=6576 msg="dir-1, tun_id=12.1.1.2"
id=65308 trace_id=174 func=ipsecdev_hard_start_xmit line=662 msg="enter IPSec interface SCMVPN_DA, tun_id=12.1.1.2"
id=65308 trace_id=174 func=_do_ipsecdev_hard_start_xmit line=222 msg="output to IPSec tunnel SCMVPN_DA, tun_id=12.1.1.2, vrf 0"
id=65308 trace_id=174 func=esp_output4 line=901 msg="IPsec encrypt/auth"
id=65308 trace_id=174 func=nipsec_set_ipsec_sa_enc line=920 msg="Trying to offload IPsec encrypt SA (p1/p2/spi={SCMVPN_DA/통합보안_01/0x7201f4e2}), npudev=-1, skb-dev=port2"
id=65308 trace_id=174 func=nipsec_set_ipsec_sa_enc line=965 msg="IPSec encrypt SA (p1/p2/spi={SCMVPN_DA/통합보안_01/0x7201f4e2}) offloading-check failed, reason_code=2."
id=65308 trace_id=174 func=ipsec_output_finish line=642 msg="send to 2.1.1.254 via intf-port2"

The response packet is generated and sent through the IPsec tunnel.

When modifying SNMP v2 or SNMP v3 configurations, it is recommended to reconfirm that the SNMP system information status remains enabled, as the setting may be unintentionally disabled during configuration changes.