SNMP accepted by Firewall rull, then getting rejected.

[erv2k007]

The community string match ( I have done this on two firewalls already).

This paticular firewall had a policy that limted SNMP, I create a new one, moved it up in priotiy and still was not getting the get - ACK.

Debug flow shows this:

14:47:48 policy-88 is matched, act-accept

14:47:48after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-88

14:47:48 checked gnum-10000f policy-4294967295, ret-matched, act-accept

14:47:48 policy-4294967295 is matched, act-drop

14:47:48 gnum-10000f check result: ret-matched, act-drop, flag-00000800, flag2-00000000

14:47:48 after check: ret-matched, act-drop, flag-00000800, flag2-00000000

14:47:48iprope_in_check() check failed on policy 0, drop



Anyone run into this?

[AEK]

Is it returning from the same path?

I mean if the query enters from FGT's port1 and exits from port2, the response should return from port2 and exits from port1. Otherwise it is dropped.

You can check with this command:

diag sniffer packet any "some filter" 4

[erv2k007]

There is no "response". That is the point. The Packet is "accepted" via policy 88 the is dropped instantly via -4294967295.

[Debbie_FTNT]

Hey erv2k007,

the policy ID 4294967295 is strange.

If I remember correctly, "gnum-10000f" means that local-in policies are checked, and ID 4294967295 also relates to that.

EDIT: I did a bit of digging, and "gnum-10000f" in particular is interface admin permissions, things like HTTPS etc enabled on the interface.

You can dump this information in CLI with 'diagnose firewall iprope list 10000f'; on my lab FortiGate I can see this for example:

policy index=4294967295 uuid_idx=7 action=accept
flag (1): log
schedule()
cos_fwd=0 cos_rev=0
group=0010000f av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=0
misc=0
zone(1): 5 -> zone(1): 0
source(1): 0.0.0.0-255.255.255.255, uuid_idx=0,
dest(1): 192.168.100.12-192.168.100.12, uuid_idx=0,
service(5):
[1:0x0:0/(0,65535)->(13,13)] flags:0 helper:auto
[1:0x0:0/(0,65535)->(8,8)] flags:0 helper:auto
[6:0x0:0/(0,65535)->(7443,7443)] flags:0 helper:auto
[6:0x0:0/(0,65535)->(22,22)] flags:0 helper:auto
[6:0x0:0/(0,65535)->(80,80)] flags:0 helper:auto

My interface with IP 192.168.100.12 allows five services: HTTPS (I use port 7443), HTTP, SSH, PING and Security Fabric. The interface permissions do look accurately reflected.

CORRECTION:

Check your interface permissions; the FortiGate seems to treat the traffic as meant for one of its interfaces, and that interface likely has SNMP disabled, hence the traffic is dropped.

If the SNMP traffic is not meant for the FortiGate, check the destination of the traffic and make sure the FortiGate doesn't listen on that IP.

I hope this helps!

Cheers,

Debbie

[funkylicious]

if you are using trusted hosts, make sure to set the ip of snmp server in one also that snmp is enabled under the interface.

[AEK]

Can you just filter on port 161 with diag sniffer, redo the test, and share the output.