Created on
06-30-2022
01:02 AM
Edited on
04-26-2024
06:26 AM
By
Stephen_G
Description |
This article describes the behavior of debug flow when the destination address is created as IP pool or VIP on FortiGate. |
Scope |
This applies to the following scenario where the destination IP is the same as the IP pool or VIP 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) |
Solution |
The following is the static route for the destination 10.4.1.30 via Port2:
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 pieces of information shown in the debug output above:
Solution:
Remove the IP pool or VIP change to another IP pool for SNAT communication. If using a VIP already, ensure the post-translation IP is not also used as a VIP elsewhere (including a subnet or wider range) |