Skip to main content
nithincs
Staff & Editor
nithincs
Staff & Editor
May 9, 2020

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

  • May 9, 2020
  • 0 replies
  • 25253 views

Description

 

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

 

Scope

 

FortiGate.

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

 
To check the debug output, run the following commands:
 

diagnose debug reset

diagnose debug console timestamp enable

diagnose debug flow filter saddr 10.5.63.254

diagnose debug flow trace start 1000

diagnose debug enable

 

To stop debugging:

 

diagnose debug reset

diagnose debug disable

 
Flow filter debug logs appear as follows:

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 the server.
 
The traffic from WAN2 is not offloaded to the DMZ interface.
The root cause of the issue is that FortiGate does not have the ARP entry for the destination IP 172.31.132.15.
 
get system arp | grep -n 172.31.132.15
 
If the MAC address of 172.31.132.15 is not visible, resolve the ARP communication issue between FortiGate and the end server at IP address 172.31.132.15.
 

Troubleshooting tips:

Check whether FortiGate has learned the MAC address of the destination IP.

 

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

 

If the mapped server is directly connected network, then replace 'x.x.x.x' with the server IP, and if the mapped server is connected via a static route, then replace 'x.x.x.x' with the next hop 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 the FortiGate CLI.

PuTTY:

 

diagnose sniffer packet any "host x.x.x.x and arp" 4 0 l

 

Press Ctrl+C to stop it.

Terms & ConditionsAccessibility statement