Hi,
We need connect from our wifi (in separate vlan) that has only output to internet to the same router via vpn.
That its by security reasons.
Wifi outs to internet via sd-wan and vpn wan entry point is in the same sd-wan.
Connection are made but there is no traffic between both points.
Checking logs we can see that
FW01 # diagnose vpn tunnel list name "USERS1_4"
list ipsec tunnel by names in vd 0
------------------------------------------------------
name=USERS1_4 ver=1 serial=1115 wan:0->10.10.10.13:0 tun_id=172.19.1.5 tun_id6=::10.0.17.14 dst_mtu=1500 dpd-link=on weight=1
10.10.10.13 is the wifi dhcp address... (I don´t know becuse nat is not applied here)
Checking sniffer traffic in the established connection we can show that 172.19.1.5 (is the vpn address) and 172.19.2.1 (is our internal servers lan) and of course rules permits that traffic
FW01 # diagnose sniffer packet any "src 172.19.1.5" 4
interfaces=[any]
filters=[src 172.19.1.5]
2.032538 WIFI in 172.19.1.5 -> 172.19.2.1: icmp: echo request
7.054851 WIFI in 172.19.1.5 -> 172.19.2.1: icmp: echo request
But there is no echo reply
Doing a flow trace we see "reverse path check fail, drop"
FW01 # diagnose debug flow filter addr 172.19.1.5
FW01 # diagnose debug flow show function-name enable
FW01 # diagnose debug enable
FW01 # diagnose debug flow trace start 100
FW01 # id=20085 trace_id=1 func=print_pkt_detail line=5824 msg="vd-root:0 received a packet(proto=1, 172.19.1.5:1->172.19.2.1:2048) tun_id=172.19.1.5 from WIFI. type=8, code=0, id=1, seq=356."
id=20085 trace_id=1 func=init_ip_session_common line=6003 msg="allocate a new session-052e794d, tun_id=172.19.1.5"
id=20085 trace_id=1 func=rpdb_srv_match_input line=1028 msg="Match policy routing id=1: to 192.168.144.1 via ifindex-86"
id=20085 trace_id=1 func=ip_route_input_slow line=2266 msg="reverse path check fail, drop"
Any suggestion should be appreciated?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hello,
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.
Best regards.
Hi,
I tried that but no lucky.
I think that the problem is that packets that come from WIFI interface come with a vpn address and I can´t route that.
FW01 # diagnose sniffer packet any "src 172.19.1.5" 4
interfaces=[any]
filters=[src 172.19.1.5]
2.032538 WIFI in 172.19.1.5 -> 172.19.2.1: icmp: echo request
7.054851 WIFI in 172.19.1.5 -> 172.19.2.1: icmp: echo request
WIFI dhcp 10.10.0.0/16. And its why I have doubts about nat when the VPN is done.
Any other suggestion?
thanks in advance,
In the VPN policy, do you have NAT enabled ?
Usually in VPN policies, NAT should be disabled, so the network addresses do not get translated (to the vpn interface address) when they enter the VPN.
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
Hi 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.
Best regards,
Vasil
Hi Vasil,
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
config vpn ipsec phase1-interface
...
edit "WiFI-VPN"
...
set ipv4-start-ip 10.10.100.2
FG "see" a mix - Wifi "guest" interface and source addr from phase1. As result the reverse path check fails, policy (created by VPN wizard) doesn't match. Bug. Had to be "WiFI-VPN" interface.
Best regards, Ramunas
Hi Ramunas,
Thank you for your update!
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.
Best regards,
Vasil
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1688 | |
1087 | |
752 | |
446 | |
227 |
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.