Kernaali Tools“reverse path check fail, drop” means the packet failed the source-path check. Inspect a route back to the packet’s source through its actual incoming interface in the receiving VDOM. A destination route or an outbound policy route is not a substitute for that evidence.
Applies to: FortiGate FortiOS 7.4.4 IPv4 routing and feasible/strict RPF documentation. The separate kernel/ECMP example is an official KB scenario, not a claim that every RPF failure is an ECMP bug. Inter-VDOM checks below assume routed VDOM links, not transparent-mode forwarding.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Record the source and receiving context
Synthetic topology: client 192.0.2.10 reaches VDOM-A on port2, crosses a routed VDOM link into VDOM-B, then contacts server 198.51.100.20. In VDOM-B, the incoming interface is its end of the VDOM link. If the source was not translated, VDOM-B needs the appropriate route back to 192.0.2.10 through that link.
Read the failing packet’s source, destination, ingress interface and VDOM from the bounded diagnostic evidence. If NAT occurred before this hop, use the source actually visible here. Repeat the reasoning independently in each VDOM; a valid route in VDOM-A does not populate VDOM-B.
Distinguish feasible and strict RPF
The FortiOS 7.4.4 routing guide describes feasible RPF as the default: an active path back to the source via the incoming interface must exist. Strict mode requires the best return path to use that incoming interface. Check the actual strict-src-check setting; do not infer the running mode from the default alone.
get router info routing-table details 192.0.2.10
get router info routing-table database
get router info kernelThe route database contains learned candidates, the routing table shows selected routes, and the kernel FIB is the forwarding view. In the kernel output, correlate the source prefix, VDOM/VRF context and outgoing interface. Do not mistake a route to the server for the source-prefix lookup.
A displayed route can still be missing from the FIB
The official kernel-route RPF KB demonstrates a case where more equal-cost paths were displayed than an ECMP limit allowed into the kernel. The packet arrived on an interface absent from the installed paths. Use that as a reason to compare the views, not as an instruction to increase every device’s ECMP limit.
| Evidence | Next branch |
|---|---|
| No route to the source in the receiving VDOM | Correct the missing source-prefix routing design |
| Source route points through another interface | Check intended return path, strict mode and asymmetry |
| Candidate route exists but no matching installed FIB path | Inspect route selection, interface state and documented path limits |
| Source path is valid but the application still fails | Inspect destination lookup, policy/NAT and host return traffic |
Review PBR and return traffic separately
Use the routing monitor’s Policy view and route lookup with the real source, destination, protocol, ports and ingress interface. FortiOS performs policy-route lookup before the ordinary FIB lookup, but a PBR entry steering the request does not manufacture the source route needed by RPF.
Check the return direction on the server and both VDOMs. A forward policy permitting the request is distinct from routing and from policies governing new connections in the opposite direction. A ping can behave differently from a stateful TCP application on an asymmetric path.
Correct the route, then verify without weakening protection
Change only the missing or incorrect route, interface mapping or relevant routing policy after recording its old value and impact. Coordinate both VDOMs and retain independent management. Do not make src-check or asymroute relaxation the default repair; those alter security semantics rather than establish a correct return path.
Open a new authorized application connection and confirm replies traverse the intended interfaces without the RPF failure. Check existing routed networks and an intentionally denied flow. Restore the exact edited route/PBR values if the result is wrong. If a temporary debug was used, stop it and clear only its diagnostic state; do not restart the routing engine or clear every session as routine cleanup.
New protected subnet has no traffic · IKE negotiation diagnostics
Technical references
Found an issue? Send a correction with a reproducible example.