Created on
06-30-2022
01:02 AM
Edited on
12-22-2025
03:51 AM
By
Jean-Philippe_P
| Description |
This article describes the behavior of the debug flow when the destination address is created as an IP pool or a 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."--> The FortiGate received an ICMP Echo Request (type=8, code=0 → standard ping). id=20085 trace_id=147 func=fw_local_in_handler line=431 msg="iprope_in_check() check failed on policy 0, drop" --> Because the packet is destined to the FortiGate itself (local-in traffic), it is subject to local-in policies.
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). |
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 2025 Fortinet, Inc. All Rights Reserved.