FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
sagha
Staff
Staff
Article Id 355139
Description This article describes the scenario where reverse path-check failure is observed even when the route is present in the routing table via the same inbound interface.
Scope FortiOS, FortiGate.
Solution

When running debug flows, the following is observed for dropped traffic: 

 

trace_id=2 func=print_pkt_detail line=5920 msg="vd-root:0 received a packet(proto=6, 192.168.200.1:60896->10.10.10.1:443) tun_id=10.100.1.1 from VPN_12. flag [S], seq 485006843, ack 0, win 65535"
trace_id=2 func=init_ip_session_common line=6110 msg="allocate a new session-0015ab87"
trace_id=2 func=iprope_dnat_check line=5480 msg="in-[VPN_12], out-[]"
trace_id=2 func=iprope_dnat_tree_check line=824 msg="len=0"
trace_id=2 func=iprope_dnat_check line=5505 msg="result: skb_flags-02000008, vid-0, ret-no-match, act-accept, flag-00000000"
trace_id=2 func=ip_route_input_slow line=1695 msg="reverse path check fail, drop"

 

The routing table looks as follows for IP address 192.168.200.1.

 

FGT # get router info routing-table details 192.168.200.1
Routing table for VRF=0
Routing entry for 192.168.200.0/24
Known via "static", distance 10, metric 0, best
           * directly connected, VPN_01
           * directly connected, VPN_02
           * directly connected, VPN_11
           * directly connected, VPN_12

 

Despite having the route in the routing table via the VPN_12 interface, FortiGate is dropping packets. 

 

It is important to check if the route is installed in the kernel routing table with the following commands: 

 

get router info kernel 

diagnose ip route list


FGT# get router info kernel 

tab=254 vf=0 scope=0 type=1 proto=11 prio=1 0.0.0.0/0.0.0.0/0->192.168.200.0/24 pref=0.0.0.0
gwy=0.0.0.0 flag=00 hops=0 oif=80(VPN_01)
gwy=0.0.0.0 flag=00 hops=0 oif=94(VPN_02)
gwy=0.0.0.0 flag=00 hops=0 oif=77(VPN_11)

As the route is missing from the kernel routing table for VPN_12, the traffic is dropped on FortiGate with RPF check failure. 

 

In the above scenario, the route did not make it to the routing table because of ECMP limit was set to 3. 

 

FGT # config sys setting
FGT (settings) # get | grep ecm
v4-ecmp-mode        : source-ip-based
ecmp-max-paths      : 3

 

Since only 3 paths are allowed, the 4th route does not get added to the kernel and hence FortiGate ends up dropping the traffic. The route shows up in the routing-table but does not get added to the kernel. For more details regarding this, raise a ticket with the Fortinet support team.