Technical Tip: VIP policy log action status value is 'Accept: IP connection error'

[nithincs]

Description
This article describes a potential root cause of action as 'Accept: IP connection error in VIP policy logs.

Solution
Assume the following scenario:

(Server: 172.31.132.15) ----DMZ FGT wan2 10.5.52.157------- Internet

Consider the server is hosting 172.31.132.15 behind the FortiGate using the VIP configuration.
When the FortiGate wan2 is pinging IP 10.5.52.157, it will get DNAT to 172.31.132.15.

# config firewall vip
    edit "test"
        set extip 10.5.52.157
        set extintf "any"
        set portforward enable
        set mappedip "172.31.132.15"
        set protocol icmp
    next
end

# config firewall policy
    edit 3
        set name "vip"
        set srcintf "wan2"
        set dstintf "dmz"
        set srcaddr "all"
        set dstaddr "test"
        set action accept
        set schedule "always"
        set service "PING"
        set logtraffic all
    next
end

Forward traffic log for the destination 10.5.52.157 and service ping will shortlist all the traffic log of policy 3 in which action of the log shows 'Accept: IP connection error'.

Flow filter debug logs show as below:

id=20085 trace_id=11 func=print_pkt_detail line=5588 msg="vd-root:0 received a packet(proto=1, 10.5.63.254:60417->10.5.52.157:2048) from wan2. type=8, code=0, id=60417, seq=1949."
id=20085 trace_id=11 func=init_ip_session_common line=5754 msg="allocate a new session-000b15d1"
id=20085 trace_id=11 func=fw_pre_route_handler line=181 msg="VIP-172.31.132.15:60417, outdev-wan2"
id=20085 trace_id=11 func=__ip_session_run_tuple line=3409 msg="DNAT 10.5.52.157:8->172.31.132.15:60417"
id=20085 trace_id=11 func=vf_ip_route_input_common line=2598 msg="find a route: flag=04000000 gw-172.31.132.15 via dmz"
id=20085 trace_id=11 func=fw_forward_handler line=781 msg="Allowed by Policy-3:"

Flow filter logs show, DNAT information, policy and route check information.
In sniffer logs, the incoming packet to FortiGate is visible and there will be no output packet from the FortiGate to server.

The traffic from wan2 is not offloaded to DMZ interface.
The root cause of the issue is FortiGate is not having the ARP entry for destination ip 172.31.132.15.

get sys arp | grep -n 172.31.132.15

If the MAC address of 172.31.132.15 is not visible, fix the ARP communication issue between FortiGate and end server IP 172.31.132.15.

Troubleshooting tips.

Check whether FortiGate has learned the MAcaddress of destination IP.

get sys arp | grep -n "x.x.x.x"

If mapped server is directly connected network then replace 'x.x.x.x' with server IP and if mapped server is connected via static route then replace 'x.x.x.x' with next hoop gateway IP.
If the ARP entry is not available in FortiGate, then isolate the issue with ARP communication.
Run the below sniffer command in the putty session and ping IP 'x.x.x.x' from FortiGate CLI.

Putty:

# dia sniffer packet any "host x.x.x.x and arp" 6 0 l