SNMP error after FortiGate 7.2.11 to 7.4.8 upgrade

[AliK]

Hello everyone,

I have a FortiGate 400F and updated it from version 7.2.11 to version 7.4.8. I'm currently trying to access Zabbix via SNMP, but I'm getting errors. When I try manually using snmpwalk on my Ubuntu server, I get No Response From... and Timeout errors. I've tried SNMP v2 and SNMP v3, removed the AUTO settings, and still the same thing.

The servers I am testing are added as trusted hosts, SNMP is active on the interface side, there is no Local in policy, and even if I manually add and allow them, timeout errors continue.

Another server in the same src network was already accessing via SNMP before the update, so there is no problem with the firewall policies.

diagnose debug application snmpd -1
diagnose debug enable

commands do not produce any logs. They are currently being tested.

When I examine the issue at the kernel debug level (with the commands below)

diagnose debug flow filter clear
diagnose debug flow filter saddr 192.168.1.212
diagnose debug flow filter daddr 192.168.1.45
diagnose debug flow filter proto 17
diagnose debug flow filter dport 161

diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable

id=65308 trace_id=11 func=init_ip_session_common line=6204 msg="allocate a new session-31ded8f8"
id=65308 trace_id=11 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=11 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=12 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:44592->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=12 func=init_ip_session_common line=6204 msg="allocate a new session-31dee75f"
id=65308 trace_id=12 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=12 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=13 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:44592->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=13 func=init_ip_session_common line=6204 msg="allocate a new session-31def5d5"
id=65308 trace_id=13 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=13 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=14 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:44592->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=14 func=init_ip_session_common line=6204 msg="allocate a new session-31df02d1"
id=65308 trace_id=14 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=14 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=15 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:44592->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=15 func=init_ip_session_common line=6204 msg="allocate a new session-31df1092"
id=65308 trace_id=15 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=15 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=16 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:44592->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=16 func=init_ip_session_common line=6204 msg="allocate a new session-31df1e95"
id=65308 trace_id=16 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=16 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=17 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:38409->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=17 func=init_ip_session_common line=6204 msg="allocate a new session-31df6264"
id=65308 trace_id=17 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=17 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=18 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:38409->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=18 func=init_ip_session_common line=6204 msg="allocate a new session-31df7062"
id=65308 trace_id=18 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=18 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=19 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:38409->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=19 func=init_ip_session_common line=6204 msg="allocate a new session-31df7d93"
id=65308 trace_id=19 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=19 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=20 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:38409->192.168.1.45:161) tun_id=0.0.0.0 from x5. "
id=65308 trace_id=20 func=init_ip_session_common line=6204 msg="allocate a new session-31df8aa5"
id=65308 trace_id=20 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=20 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=21 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:38409->192.168.1.45:161) tun_id=0.0.0.0 from x5. "id=65308 trace_id=21 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 172.16.1.212:38409->172.16.1.45:161) tun_id=0.0.0.0 from x5. "

Even if I allow this traffic with local-in-policy (I also tried src and service all), the traffic still drops to policy 0.

Any idea what could be the problem?
Thanks,

[kaman]

Hi AliK,

From the attached debug logs, I can see you are getting an error 'flag=80000000 gw-0.0.0.0 via root' and 'iprope_in_check() check failed on policy 0, drop'

id=65308 trace_id=11 func=init_ip_session_common line=6204 msg="allocate a new session-31ded8f8"
id=65308 trace_id=11 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=11 func=fw_local_in_handler line=620 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=12 func=print_pkt_detail line=6005 msg="vd-root:0 received a packet(proto=17, 192.168.1.212:44592->192.168.1.45:161) tun_id=0.0.0.0 from x5.

Double-confirm once and check the SNMP request is coming on which Port and the SNMP service is running on which Port.

If SNMP traffic is for different interfaces, it is mandatory to create a Firewall Policy and allow SNMP traffic and remove all Local-in-policy.

Please refer to the documents below for more information:

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-snmpwalk-is-getting-failed/ta-p/2693...

https://community.fortinet.com/t5/FortiGate/Technical-Tip-UDP-port-shows-as-open-as-per-diagnose-sys...

If the issues are persistent, collect the below output and share:

CLI1:
diag debug application snmpd -1
diag debug enable

CLI2"
diag sniffer packet any "port 161 or 162" 6 0 l

If you have found a solution, please like and accept it to make it easily accessible to others.

Regards,
Aman

[AliK]

The FortiGate's port X5 has a network of 192.168.1.x. The IP address of the X5 port is 192.168.1.45, and SNMP is enabled. The Zabbix machine on the same port, 192.168.1.212, tries to connect via SNMP and receives this error. There is no Local-in-Policy defined on the FortiGate; I removed all of them.

CLI1:
diag debug application snmpd -1
diag debug enable

The CLI command does not produce any output, only the following message appears intermittently

snmpd: updating cache: idx_cache (:)
snmpd: updating cache: idx_cache (:)

CLI2"
diag sniffer packet any "port 161 or 162" 6 0 l

When I run this cli I get the following result:

2025-09-18 14:33:14.239962 x5 in 192.168.1.212.34648 -> 192.168.1.45.161: udp 41
0x0000 0000 0000 0001 0050 56ba 8b8e 0800 4500 .......PV.....E.
0x0010 0045 2cb0 4000 4011 b2d6 ac10 01d4 ac10 .E,.@.@.........
0x0020 012d 8758 00a1 0031 ec92 3027 0201 0104 .-.X...1..0'....
0x0030 0670 7562 6c69 63a1 1a02 0472 12c5 5702 .public....r..W.
0x0040 0100 0201 0030 0c30 0a06 062b 0601 0201 .....0.0...+....
0x0050 0105 00 ...

2025-09-18 14:33:15.241042 x5 in 192.168.1.212.34648 -> 192.168.1.45.161: udp 41
0x0000 0000 0000 0001 0050 56ba 8b8e 0800 4500 .......PV.....E.
0x0010 0045 2ce7 4000 4011 b29f ac10 01d4 ac10 .E,.@.@.........
0x0020 012d 8758 00a1 0031 ec92 3027 0201 0104 .-.X...1..0'....
0x0030 0670 7562 6c69 63a1 1a02 0472 12c5 5702 .public....r..W.
0x0040 0100 0201 0030 0c30 0a06 062b 0601 0201 .....0.0...+....
0x0050 0105 00 ...

2025-09-18 14:33:16.242104 x5 in 192.168.1.212.34648 -> 192.168.1.45.161: udp 41
0x0000 0000 0000 0001 0050 56ba 8b8e 0800 4500 .......PV.....E.
0x0010 0045 30bb 4000 4011 aecb ac10 01d4 ac10 .E0.@.@.........
0x0020 012d 8758 00a1 0031 ec92 3027 0201 0104 .-.X...1..0'....
0x0030 0670 7562 6c69 63a1 1a02 0472 12c5 5702 .public....r..W.
0x0040 0100 0201 0030 0c30 0a06 062b 0601 0201 .....0.0...+....
0x0050 0105 00 ...

2025-09-18 14:33:17.242805 x5 in 192.168.1.212.34648 -> 192.168.1.45.161: udp 41
0x0000 0000 0000 0001 0050 56ba 8b8e 0800 4500 .......PV.....E.
0x0010 0045 315c 4000 4011 ae2a ac10 01d4 ac10 .E1\@.@..*......
0x0020 012d 8758 00a1 0031 ec92 3027 0201 0104 .-.X...1..0'....
0x0030 0670 7562 6c69 63a1 1a02 0472 12c5 5702 .public....r..W.
0x0040 0100 0201 0030 0c30 0a06 062b 0601 0201 .....0.0...+....
0x0050 0105 00 ...

2025-09-18 14:33:18.243860 x5 in 192.168.1.212.34648 -> 192.168.1.45.161: udp 41
0x0000 0000 0000 0001 0050 56ba 8b8e 0800 4500 .......PV.....E.
0x0010 0045 34fd 4000 4011 aa89 ac10 01d4 ac10 .E4.@.@.........
0x0020 012d 8758 00a1 0031 ec92 3027 0201 0104 .-.X...1..0'....
0x0030 0670 7562 6c69 63a1 1a02 0472 12c5 5702 .public....r..W.
0x0040 0100 0201 0030 0c30 0a06 062b 0601 0201 .....0.0...+....
0x0050 0105 00 ...

2025-09-18 14:33:19.244841 x5 in 192.168.1.212.34648 -> 192.168.1.45.161: udp 41
0x0000 0000 0000 0001 0050 56ba 8b8e 0800 4500 .......PV.....E.
0x0010 0045 36dc 4000 4011 a8aa ac10 01d4 ac10 .E6.@.@.........
0x0020 012d 8758 00a1 0031 ec92 3027 0201 0104 .-.X...1..0'....
0x0030 0670 7562 6c69 63a1 1a02 0472 12c5 5702 .public....r..W.
0x0040 0100 0201 0030 0c30 0a06 062b 0601 0201 .....0.0...+....
0x0050 0105 00 ...

[princes]

Hi,

Kindly run a packet sniffer for SNMP server IP and see what is the source IP selected from FortiGate.

If the devices are in HA and the destination is not reachable through management interface you might need to disable ha-direct .

This will ensure the outgoing traffic from a reachable source address.

If you have found a solution, please like and accept it.

Regards,

Prince 

[AliK]

The devices are not HA and only operate via Vdom. There is no Vdom configuration. The traffic's srv and dst are on the same interface, but the problem persists. There is currently no local in policy on the device.

[kaman]

Hi AliK,

The attached sniffer capture indicates that traffic is entering through interface X5 but not exiting.

2025-09-18 14:33:14.239962 x5 in 192.168.1.212.34648 -> 192.168.1.45.161: udp 41
2025-09-18 14:33:15.241042 x5 in 192.168.1.212.34648 -> 192.168.1.45.161: udp 41

> What is the SNMP version?
> Check if the IP of the snmp server is added to the trusted hosts (as well as in the admin user's trusted hosts, if trusted hosts are used)
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Troubleshooting-SNMP-query-failure-f...

> Check if there is any SNMPD crashes. The crashlog can be seen in 'diagnose debug crashlog read'.

> Gracefully restart snmpd process:

diagnose test application snmpd 99
fnsysctl killall snmpd

> Verify if the SNMP port 161 is in use by FortiGate, use the following command to show a corresponding entry:

diag sys udpsock | grep 161

Please refer to the document below and check ha-direct is enabled or disabled. Try to disable and check the behaviour.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-SNMP-process-is-not-listening/ta-p/256658

If you have found a solution, please like and accept it to make it easily accessible to others.

Regards,
Aman