This article describes the behavior of debug flow when the destination address is created as IP pool on FortiGate.
This applies to the following scenario where the destination IP is the same as the IP pool on FortiGate.
The following is the scenario:
Client (10.4.25.192) -> FortiGate (IP pool - 10.4.1.30) -> Port2 Destination (10.4.1.30)
The following is the static route for the destination 10.4.1.30 via Port2:
FGVM (VDOM_TEST) # get router info routing-table database | grep 10.4.1.30
The following is the output when the debug flow is executed for the traffic:
FGVM (VDOM_TEST) # id=20085 trace_id=147 func=print_pkt_detail line=5665 msg="vd-VDOM_TEST:0 received a packet(proto=1, 10.4.25.192:1->10.4.1.30:2048) from ssl.VDOM_TEST. type=8, code=0, id=1, seq=217."
id=20085 trace_id=147 func=fw_local_in_handler line=431 msg="iprope_in_check() check failed on policy 0, drop"
There are 2 important information on the debug output shown above:
1) The traffic is stopping at the 'VDOM_TEST' instead of Port2 as configured on the static route.
This can be seen from the output 'find a route: flag=80000000 gw-10.4.1.30 via VDOM_TEST'.
2) There is no matching Policy created for the destination traffic which explains the output message 'iprope_in_check() check failed on policy 0, drop'.
Remove the IP pool or change to another IP pool for SNAT communication.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2023 Fortinet, Inc. All Rights Reserved.