Technical Tip: Understanding 'policyid=0' drops for local-in-policy traffic on FortiGate

The user might see that the connection is failing in local logging, and some specific services like SNMP, PING, HTTPS, HTTP, FTM, or telnet access are dropping with local in policy, including policy ID 0. But there is no policy ID 0 or implicit deny showing in the configuration for local-in-policy. 

This behavior is expected and applies to traffic destined to the FortiGate itself. Also, the implicit deny and the policy id '0' for the local-in-policy is hard-coded.

Example log:

date=2026-01-12 time=03:01:57 eventtime=1768215716811909981 tz="-0800" logid="0001000014" type="traffic" subtype="local" level="notice" vd="root" srcip=10.61.18.4 srcport=49812 srcintf="port3" srcintfrole="undefined" dstip=10.61.27.159 dstport=80 dstintf="root" dstintfrole="undefined" srccountry="Reserved" dstcountry="Reserved" sessionid=349842 proto=6 action="deny" policyid=0 policytype="local-in-policy" service="HTTP" trandisp="noop" app="Web Management" duration=0 sentbyte=0 rcvdbyte=0 sentpkt=0 rcvdpkt=0 crscore=5 craction=262144 crlevel="low" msg="Connection Failed"

When a traffic log shows subtype=local, it means the traffic is destined to the FortiGate itself and not being forwarded through the device. This type of traffic targets the management or control plane and commonly includes services such as HTTP/HTTPS access to the GUI, SSH, SNMP, ping, and routing or HA protocols. Because the destination is the FortiGate, standard IPv4/IPv6 firewall policies are not applied to this traffic.

Local-in traffic is evaluated using the local-in policy framework, shown in logs as policytype=local-in-policy. FortiGate first checks any configured local-in policies, then the destination interface 'set allowaccess <>' settings. If the traffic is not explicitly permitted by either, a built-in implicit deny is applied to protect the FortiGate management plane.

Although FortiOS does not display an implicit local-in deny in the configuration or GUI, such a deny always exists internally.

To allow traffic if it drops in such a way, simply allowing the service at the interface level can resolve the issue.

CLI:

config system interface
    edit portx
        set allowaccess <service name>

    next

end

Related article:
Technical Tip: Creating a Local-In policy (IPv4 and IPv6) on GUI