Description
This article describes the causes behind an issue where, when attempting an API call, the message 'iprope_in_check() check failed on policy 0, drop' appears. A solution is provided.
Scope
FortiGate 7.X.
Solution
Normal example:
- Debug flow outputs:
fw1 # id=65308 trace_id=2573 func=print_pkt_detail line=5842 msg="vd-root:0 received a packet(proto=6, X.X.X.X:59482->Y.Y.Y.Y:443) tun_id=0.0.0.0 from INT_LAG. flag [S], seq 2556992730, ack 0, win 29200"
id=65308 trace_id=2573 func=ip_session_confirm_final line=3087 msg="npu_state=0x0, hook=1"
id=65308 trace_id=2574 func=print_pkt_detail line=5842 msg="vd-root:0 received a packet(proto=6, Y.Y.Y.Y:443->X.X.X.X:59482) tun_id=0.0.0.0 from local. flag [S.], seq 1983244691, ack 2556992731, win 28960"
id=65308 trace_id=2574 func=resolve_ip_tuple_fast line=5930 msg="Find an existing session, id-01de19e1, reply direction"
id=65308 trace_id=2575 func=print_pkt_detail line=5842 msg="vd-root:0 received a packet(proto=6, X.X.X.X:59482->Y.Y.Y.Y:443)
- Debug flow httpsd outputs:
[httpsd 901 - 1692775703 info] endpoint_process_req_vdom[1024] -- new API request (action='select',path='system',name='usb-log',vdom='root',user='admin')
[httpsd 901 - 1692775703 info] endpoint_process_req_vdom[1030] -- completed API request (rss_pre=11156, rss_post=11156, rss_delta=0)
[httpsd 901 - 1692775703 info] fweb_debug_final[318] -- Completed GET request for "/api/v2/monitor/system/usb-log" (HTTP 200)
[httpsd 901 - 1692775705 info] fweb_debug_init[428] -- New GET request for "/api/v2/monitor/firewall/address-fqdns" from "10.10.10.123:50067"
Abnormal example:
- Debug flow outputs:
id=65308 trace_id=2374 func=print_pkt_detail line=5842 msg="vd-root:0 received a packet(proto=6, X.X.X.X:44802->Y.Y.Y.Y:443) tun_id=0.0.0.0 from INT_LAG. flag [S], seq 746169220, ack 0, win 29200"
id=65308 trace_id=2374 func=__iprope_check_one_policy line=2277 msg="policy-4294967295 is matched, act-drop"
id=65308 trace_id=2374 func=__iprope_check line=2324 msg="gnum-10000f check result: ret-matched, act-drop, flag-00000800, flag2-00000000"
id=65308 trace_id=2374 func=iprope_policy_group_check line=4730 msg="after check: ret-matched, act-drop, flag-00000800, flag2-00000000"
id=65308 trace_id=2374 func=fw_local_in_handler line=615 msg="iprope_in_check() check failed on policy 0, drop"
id=65308 trace_id=2375 func=print_pkt_detail line=5842 msg="vd-root:0 received a packet(proto=6, X.X.X.X:44802->Y.Y.Y.Y:443) tun_id=0.0.0.0 from INT_LAG. flag [S], seq 746169220, ack 0, win 29200"
- Debug flow httpsd outputs:
[httpsd 794 - 1692774456 info] fweb_debug_init[428] -- New GET request for "/api/v2/monitor/system/usb-log" from "192.168.251.11:8206"
[httpsd 794 - 1692774456 info] endpoint_process_req_vdom[1030] -- completed API request (rss_pre=14432, rss_post=14432, rss_delta=0)
[httpsd 794 - 1692774456 info] fweb_debug_final[318] -- Completed GET request for "/api/v2/monitor/system/usb-log" (HTTP 200)
[httpsd 795 - 1692774461 info] fweb_debug_init[428] -- New GET request for "/api/v2/monitor/system/usb-log" from "192.168.251.11:8206"
...
If trusthost is set only for api-user as above, the 'iprope_in_check() check failed on policy 0, drop' issue occurs.
The trusthosts of api-user are applied only for API access and, in this specific scenario to access api-user, the API client IP address should be matched by both the trusthost list of 'system admin' and 'system api-user'. For example:
config system admin
edit "admin"
set trusthost1 X.X.X.X 255.255.255.255 <-- API client's IP address.
set accprofile "super_admin"
set vdom "root"
set password ***
next
end
config system api-user
edit "api_adminuser"
set api-key ***
set accprofile "api-profile-test"
set vdom "root"
config trusthost
edit 1
set ipv4-trusthost X.X.X.X 255.255.255.255 <-- api client's IP address
next
end
next
end
Related articles:
