Do you have reverse path forwarding , in strict mode ?
If you dont, try to ping the source from the fortigate. If you cannot ping the source from fortigate, it means that fortigate do not know a valid path for the source of the packets (if you are in strict mode, Fortigate must know the "Best" path).
So to solve your problem you can make a static route in the Fortigate pointing to the source of the packets, and then the "reverse path check fail" error will not happen.
Hi, I have the same issue. Dial-up IPsec vpn over WiFi on the same router is up, but data don't flow. Debug flow showed "reverse path check fail, drop". I checked a routing table on my Fortigate - there are no issues, as soon I connect, two new routes appear (one for Wifi address and one for vpn). I wondered, but I added set src-check disable to the wifi interface. Then debug flow showed that no policy matches (no matter, that wizard had created required policy!) to the flow and then I noticed, that the packet comes not from ipsec interface, but from wifi interface... It explained why RPF check failed and why no policy matched. I added one more policy and now sniffer shows that I can reach my printer, but I can't get the ping packet back - it is dropped on the way back.
It is buggy FG place. Because FotiAP works in tunnel mode, we have "tunnel in tunnel" situation and FortiGate fails. I believe that it should be possible change AP working mode, add VLAN to it and probably it should work. But I don't want such "solution". BR, Ramunas
Normally you don't need to enable "set src-check disable" this setting is intended for other use cases. I guess would be much easier if you share a debug output from that traffic sample:
diagnose debug reset diagnose debug flow filter addr XXXXXX <---- here type clients IP address that should experience the issue diag debug flow show function-name enable diag debug flow show iprope enable diagnose debug console timestamp enable diagnose debug flow trace start <number of packets> - begin of debugging diagnose debug enable - enable the debug
diagnose debug disable - to stop the debug
Alternatively you can proceed and open a new support ticket with the TAC, but I am certain that this behavior is a matter of configuration settings and not a bug.
thank you for response. I have solved it in other way, so just for illustration. A sniffer it shows better than debug flow:
(connected over ipsec vpn, over wifi with FortiAP) 4.974523 guest in 10.10.100.2 -> 192.168.0.221: icmp: echo request 9.905074 guest in 10.10.100.2 -> 192.168.0.221: icmp: echo request (guest - WiFi interface, created by WiFi wizard)
config system interface ... edit "guest" set vdom "root" set ip 10.10.20.1 255.255.255.0
I see what is the problem. Fortigate sniffer is capturing the packets when they are received in the CPU. The "in" incoming direction is not a decision on the Fortigate, so if you see wrong interface on incoming I guess there is something else going wrong there.
I never came across about such bug/firmware issue, where the interface is "mixed" with another interface. I really doubt that it's possible to be honest, as each interface has different kernel index.
The results (RPF check fail) as you mentioned are expected, but I would advise you to open a support ticket. I think that collecting debug output as shared above can give us more insight.
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.