medium

Troubleshooting FortiGate interface policies and IPS-based traffic blocking

Confirmed 9/17/2026

Problem

Traffic may be blocked by an interface policy even though the forwarding policy permits it. Interface policies are evaluated first when traffic enters their configured interface and last when traffic exits it. Because IPS performs bidirectional packet inspection, each interface policy creates two IPROPE entries: one for the configured direction and another for return traffic.

Symptoms

For outbound traffic, debug flow shows that the firewall policy accepts and forwards the packet to IPS, after which Application Control drops it. Forward Traffic logs can therefore report action="accept" while Application Control logs report policytype="interface-policy" and action="block". For ingress traffic, IPS can discard the packet before it reaches the kernel forwarding path, resulting in Application Control logs but no debug flow output. Sessions matching an interface policy are excluded from hardware offload and can show no_ofld_reason: intf-dos.

Environment

FortiGate. The examples use interface policies with the Application Control profile "lab" to detect and block ICMP traffic to 8.8.8.8. The outbound policy is attached to "virtual-wan-link"; the ingress policy is attached to "internal" for source 10.85.85.100. Interface-policy Web Filter inspection supports HTTP only, not HTTPS. Matching traffic is exempt from hardware offloading, although NTURBO or IPSA acceleration may still be available depending on the hardware.

FortiOS version

7.4.6

Root Cause

The interface policy sends matching traffic to IPS for profile inspection. If Application Control blocks the detected application, such as ICMP, IPS drops the packet independently of the forwarding policy result. On ingress, this inspection occurs before the kernel makes its forwarding decision; on egress, it occurs after the kernel selects the outgoing interface.

Solution

Review the interface-policy configuration and identify its interface, addresses, services, and security profiles. The outbound example applies Application Control profile "lab" to ICMP traffic destined for 8.8.8.8 through the SD-WAN interface:

config firewall interface-policy
    edit 1
        set uuid 30c26f5a-bb19-51ef-a3d8-79a9b27a02ce
        set interface "virtual-wan-link"
        set srcaddr "all"
        set dstaddr "8.8.8.8"
        set service "ALL_ICMP"
        set application-list-status enable
        set application-list "lab"
    next

Account for bidirectional IPS inspection. Two IPROPE entries are generated for each interface policy, so both packets sent to 8.8.8.8 and packets returned from 8.8.8.8 can be inspected. In this example, both entries use policy index 1, flag nids_raw, and ips_view=1:

policy index=1 uuid_idx=0 action=accept
flag (2000): nids_raw
schedule()
cos_fwd=0  cos_rev=0
group=00050005 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=1
misc=0
zone(2): 5 6 -> zone(2): 5 6
source(1): 0.0.0.0-255.255.255.255, uuid_idx=603,
dest(1): 8.8.8.8-8.8.8.8, uuid_idx=889,
service(1):
        [1:0x0:0/(0,65535)->(0,65535)] flags:0 helper:auto

policy index=1 uuid_idx=0 action=accept
flag (2000): nids_raw
schedule()
cos_fwd=0  cos_rev=0
group=00050005 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=1
misc=0
zone(2): 5 6 -> zone(2): 5 6
source(1): 8.8.8.8-8.8.8.8, uuid_idx=889,
dest(1): 0.0.0.0-255.255.255.255, uuid_idx=603,
service(1):
        [1:0x0:0/(0,65535)->(0,65535)] flags:0 helper:auto

Start filtered flow and IPS debugging. Replace x.x.x.x with the relevant source or destination IP address, x in the protocol filter with the traffic protocol ID, and x in the port filter with the destination port:

diagnose debug flow disable
diagnose debug flow reset
diagnose debug flow filter addr x.x.x.x
diagnose debug flow filter proto x
diagnose debug flow filter port x
diagnose ips debug enable detect
diagnose ips debug enable packet
diagnose debug console timestamp enable
diagnose debug enable

Reproduce outbound traffic and correlate the kernel and IPS results. In this example, policy 1 permits and SNATs the packet, then sends it to IPS. Application Control detects ICMP and drops it:

id=65308 trace_id=218 func=__iprope_check_one_policy line=2161 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
id=65308 trace_id=218 func=__iprope_check_one_policy line=2161 msg="checked gnum-4e20 policy-7, ret-matched, act-accept"
id=65308 trace_id=218 func=__iprope_check_one_policy line=2397 msg="policy-7 is matched, act-accept"
id=65308 trace_id=218 func=__iprope_check line=2444 msg="gnum-4e20 check result: ret-matched, act-accept, flag-00202000, flag2-00000000"
id=65308 trace_id=218 func=get_new_addr line=1295 msg="find SNAT: IP-10.128.202.29(from IPPOOL), port-56155"
id=65308 trace_id=218 func=__iprope_check_one_policy line=2397 msg="policy-1 is matched, act-accept"
id=65308 trace_id=218 func=__iprope_fwd_check line=860 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-1"
id=65308 trace_id=218 func=iprope_fwd_auth_check line=889 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-1"
id=65308 trace_id=218 func=__iprope_check line=2427 msg="gnum-100016, check-ffffffbffc02ca84"
id=65308 trace_id=218 func=iprope_policy_group_check line=4955 msg="after check: ret-no-match, act-accept, flag-00000000, flag2-00000000"
id=65308 trace_id=218 func=iprope_reverse_dnat_check line=1375 msg="in-[internal], out-[wan2], skb_flags-02000000, vid-0"
id=65308 trace_id=218 func=iprope_reverse_dnat_tree_check line=928 msg="len=0"
id=65308 trace_id=218 func=fw_forward_handler line=997 msg="Allowed by Policy-1: SNAT"
id=65308 trace_id=218 func=ip_session_confirm_final line=3213 msg="npu_state=0x1000, hook=4"
id=65308 trace_id=218 func=ids_receive line=464 msg="send to ips"
id=65308 trace_id=218 func=__ip_session_run_tuple line=3532 msg="SNAT 10.85.85.100->10.128.202.29:56155"
id=65308 trace_id=218 func=dev_l2ips_handle_skb line=834 msg="FOS handle dos,intf,acl policy."
[2597@-1]ips_decode_encap: got a l2 packet, id=60386, ether=0x800, size=88, l2_len=14
[2597@-1]ips_scan_range_get_range: found in cache, view:3 proto:1 range:2048
[2597@-1]ips_create_session: set ignore_app_after_size from 204800 to 2048 by dependencies of 0 Root
[2597@4792]ipsa_adapter_search_prepare: service: unknown
[2597@4792]proc_results: ipsa results:
[2597@4792]ips_match_rule: pattern matched 16206,19243: ICMP
[2597@4792]ips_match_rule: matched rule 16206 19243 ICMP (weight:1)
[2597@4792]ips_match_candidates: set best rule 16206 19243 ICMP
[2597@4792]ips_handle_pkt_verdict: drop a packet, size=88

Compare Forward Traffic and Application Control logs for outbound blocking. The Forward Traffic record can show acceptance by firewall policy 1:

date=2024-12-15 time=14:04:39 eventtime=1734300278783331899 tz="-0800" logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" srcip=10.85.85.100 srcname="win-host-1.test.lab" identifier=1 srcintf="internal" srcintfrole="lan" dstip=8.8.8.8 dstintf="wan2" dstintfrole="undefined" srccountry="Reserved" dstcountry="United States" sessionid=3848429 proto=1 action="accept" policyid=1 policytype="policy" poluuid="8c359002-a0a6-51ef-e2a9-9de7c40af93a" policyname="Internet" service="PING" trandisp="snat" transip=10.128.202.29 appcat="unscanned" duration=75 sentbyte=240 rcvdbyte=0 sentpkt=4 rcvdpkt=0 vwlid=0 osname="Windows" srcswversion="10" mastersrcmac="bc:24:11:90:bc:6b" srcmac="bc:24:11:90:bc:6b" srcserver=0

The corresponding Application Control record identifies interface policy 1 and the ICMP block:

date=2024-12-15 time=14:03:37 eventtime=1734300217734682039 tz="-0800" logid="1059028705" type="utm" subtype="app-ctrl" eventtype="signature" level="warning" vd="root" appid=16206 srcip=10.128.202.29 srccountry="Reserved" dstip=8.8.8.8 dstcountry="United States" icmpid="0xdb5b" icmptype="0x08" icmpcode="0x00" srcintf="wan2" srcintfrole="undefined" dstintf="wan2" dstintfrole="undefined" proto=1 service="PING" direction="outgoing" policyid=1 poluuid="30c26f5a-bb19-51ef-a3d8-79a9b27a02ce" policytype="interface-policy" sessionid=4792 applist="lab" action="block" appcat="Network.Service" app="ICMP" hostname="8.8.8.8" incidentserialno=93323732 msg="Network.Service: ICMP" apprisk="elevated"

For ingress testing, inspect the policy bound to the receiving interface. This example applies profile "lab" as traffic from 10.85.85.100 enters "internal":

config firewall interface-policy
    edit 2
        set uuid 1e764178-bb23-51ef-d240-a38c134cdb19
        set logtraffic all
        set interface "internal"
        set srcaddr "10.85.85.100"
        set dstaddr "all"
        set service "ALL"
        set application-list-status enable
        set application-list "lab"
    next
end

Reproduce ingress traffic. Do not treat missing debug flow output as proof that FortiGate did not receive the packet. IPS can block ingress traffic before it enters the kernel forwarding path. The IPS output in this example is:

[21331@2]ips_match_rule: pattern matched 16206,19243: ICMP
[21331@2]ips_match_rule: matched rule 16206 19243 ICMP (weight:1)
[21331@2]ips_match_candidates: set best rule 16206 19243 ICMP
[21331@2]ips_set_pkt_verdict: action=DROP
[21331@2]ips_report_alert_va_internal: v_id=16206, a_id=19243, log=0, log_pkt=0
[21331@2]ips_log: id=16206 conf=0xc5, action=1
[21331@2]match_app: disarm ftgd queries when request is to be blocked.
[21331@2]ips_process_event: ctx 3: 4 => 3
[21331@2]ips_handle_pkt_verdict: drop a packet, size=74
[21331@2]ips_process_event: ctx 3: 3 => 5

The Application Control log confirms policy 2 performed the block:

date=2024-12-15 time=14:26:08 eventtime=1734301568493005459 tz="-0800" logid="1059028705" type="utm" subtype="app-ctrl" eventtype="signature" level="warning" vd="root" appid=16206 srcip=10.85.85.100 srccountry="Reserved" dstip=8.8.8.8 dstcountry="United States" icmpid="0x0001" icmptype="0x08" icmpcode="0x00" srcintf="internal" srcintfrole="lan" dstintf="wan2" dstintfrole="undefined" proto=1 service="PING" direction="outgoing" policyid=2 poluuid="1e764178-bb23-51ef-d240-a38c134cdb19" policytype="interface-policy" sessionid=3853238 applist="lab" action="block" appcat="Network.Service" app="ICMP" hostname="8.8.8.8" incidentserialno=93323750 msg="Network.Service: ICMP" apprisk="elevated"

Check session offload status when performance or acceleration is part of the investigation. A matching session can display npu_state=0x001008, offload=0/0, ips_offload=0/0, and no_ofld_reason: intf-dos:

session info: proto=1 proto_state=00 duration=16 expire=46 timeout=0 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=log may_dirty npu ndri f00
statistic(bytes/packets/allow_err): org=240/4/1 reply=240/4/1 tuples=3
tx speed(Bps/kbps): 14/0 rx speed(Bps/kbps): 14/0
orgin->sink: org pre->post, reply pre->post dev=25->6/6->25 gwy=10.128.202.1/10.85.85.100
hook=post dir=org act=snat 10.85.85.100:1->1.1.1.1:8(10.128.202.29:56250)
hook=pre dir=reply act=dnat 1.1.1.1:56250->10.128.202.29:0(10.85.85.100:1)
hook=post dir=reply act=noop 1.1.1.1:1->10.85.85.100:0(0.0.0.0:0)
src_mac=bc:24:11:90:bc:6b
misc=0 policy_id=1 pol_uuid_idx=763 auth_info=0 chk_client_info=0 vd=0
serial=003acfea tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id=80000000 ngfwid=n/a
npu_state=0x001008
npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000
vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0, ha_divert=0/0
no_ofld_reason:  intf-dos

After collecting the required output, stop and reset debugging:

diagnose debug disable
diagnose debug reset

Verification

Confirm the responsible inspection point by correlating policy IDs, UUIDs, interfaces, session IDs, and timestamps. For outbound inspection, debug flow should show the firewall policy accepting the packet and sending it to IPS, while the Application Control log shows policytype="interface-policy" and action="block". For ingress inspection, an IPS DROP and matching Application Control event may be present without any debug flow output because the packet was discarded before kernel forwarding. The session table can additionally confirm exclusion from hardware offload through offload=0/0 and no_ofld_reason: intf-dos.

Community rating

— / 5 (0)

Discussion (0)

No comments yet.