Skip to main content
erv2k007
erv2k007
New Member
June 10, 2025
Question

SNMP accepted by Firewall rull, then getting rejected.

  • June 10, 2025
  • 3 replies
  • 3492 views

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?

3 replies

AEK
SuperUser
AEK
SuperUser
June 10, 2025

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
AEK
    erv2k007
    erv2k007Author
    New Member
    June 11, 2025

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

    Debbie_FTNT
    Staff & Editor
    Debbie_FTNT
    Staff & Editor
    June 12, 2025

    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

      AEK
      SuperUser
      AEK
      SuperUser
      June 12, 2025

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

      AEK
      snowbo
      snowbo
      New Member
      April 28, 2026

      did you get any further with this? I am having exactly the same issue at the moment.

       

      Terms & ConditionsAccessibility statement