A policy route between VDOMs can match the intended path while traffic is dropped with reverse path check fail, drop. RPF uses kernel routes, not policy routes; adding a policy route does not create the kernel route back to the packet’s source.
If the VDOM-link design requires policy routing and cannot use a suitable kernel return route, disable RPF on the receiving VDOM-link interface.
Fix the RPF drop on the receiving VDOM link
In this example, traffic enters VDOM-B through its existing vlink-B interface. Use that receiving interface’s name, not the sending VDOM’s link. With multiple VDOMs enabled, run the following from the top-level CLI as a global administrator; leave a VDOM context with next and end first.
config global
config system interface
edit "vlink-B"
set src-check disable
next
end
endThis disables source-address validation for all traffic arriving on vlink-B. Keep the permitted source networks and services restricted by VDOM-B’s firewall policies. The policy route still needs a reachable next hop and a working return path.
Retry the original client connection. If the RPF drop was the cause, the packet can now pass that check. If traffic still fails, use the short flow trace in VDOM-B to identify the next drop; stop and clear the debug afterward. Use diagnose firewall proute list to confirm the intended policy route.
To restore RPF on this interface, use the same block with set src-check enable. Fortinet documents the per-interface setting; VDOM-wide asymroute is unnecessary for this fix.
Alternative: add the missing kernel return route
If a static return route fits the design, keep RPF enabled. For a source network behind VDOM-A’s 10.255.0.1/30 link, VDOM-B needs a route back to 192.0.2.0/24 via 10.255.0.1 on vlink-B. Run this inside VDOM-B:
config router static
edit 0
set dst 192.0.2.0 255.255.255.0
set gateway 10.255.0.1
set device "vlink-B"
next
endedit 0 creates a route. Edit the existing route ID instead if it only has the wrong gateway or interface.
Use get router info routing-table details 192.0.2.10 and get router info kernel to check the installed return path. Feasible RPF accepts a feasible path through the incoming interface; strict RPF requires the best path there. strict-src-check disable selects feasible RPF and does not disable RPF.
If a route is displayed but its ingress path is absent from the kernel, compare route selection and the documented ECMP installation limit.