Connection from Wifi (internet only) to VPN in the same router

[bitabit]

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?

[Vando_Pereira]

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.

[bitabit]

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,

[Vando_Pereira]

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.

[ramunas]

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

[vtsonev]

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

[ramunas]

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

[vtsonev]

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