Created on 11-04-2024 07:14 AM Edited on 11-04-2024 07:17 AM By Jean-Philippe_P
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"
The routing table looks as follows for IP address 192.168.200.1.
FGT # get router info routing-table details 192.168.200.1
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
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 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
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. |
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 2024 Fortinet, Inc. All Rights Reserved.