Technical Tip: Debug flow behavior when destination address is created as IP pool or VIP on FortiGate

This article describes the behavior of the debug flow when the destination address is created as an IP pool or a VIP on FortiGate.

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).

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
S *> 10.4.1.30/32 [10/0] via 192.168.0.1, Port2

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=init_ip_session_common line=5836 msg="allocate a new session-e49b249a" --> No existing session found, so a new session entry is created.
id=20085 trace_id=147 func=iprope_dnat_check line=5005 msg="in-[ssl.VDOM_TEST], out-[]" -->Ingress interface confirmed as ssl.VDOM_TEST; no egress interface determined yet.
id=20085 trace_id=147 func=iprope_dnat_tree_check line=833 msg="len=0" --> No Destination NAT (DNAT/VIP) rules apply to this packet.
id=20085 trace_id=147 func=iprope_dnat_check line=5018 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"  --> DNAT check result: no match → proceed without NAT (normal for traffic not hitting a VIP).
id=20085 trace_id=147 func=vf_ip_route_input_common line=2584 msg="find a route: flag=80000000 gw-10.4.1.30 via VDOM_TEST"  -->Routing lookup: The destination IP 10.4.1.30 is considered local to the FortiGate. 

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:

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'.

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).