I have an SSL VPN - nothing fancy on a FortiGate 601E/v6.4.7.
Only a single portal with a single group. Very basic. 1 DIA interface and 1 LAN interface. The portal has both tunnel and web access enabled.
I can connect w/ both tunnel and web – no issues.
Can’t pass traffic over split tunnel. Diag shows "2 func=ip_route_input_slow line=2264 msg=“reverse path check fail, drop”
How can this happen, it’s a virtual ip being issued by the forti’s SSL VPN. I tried adding a route back to that fake VPN subnet but no dice. Support had no idea what to do. TY
I would start with getting to 6.4.14 or moving to 7.0.13/7.2.6, there have been several major vulnerabilities specifically with the SSL VPN feature which affect you since you’re using it.
You have a split tunnel. Your reverse source ip, is not in any destination policy for your VPN, therefore no route is pushed, your VPN client cannot find the reverse route.
Use a full tunnel or push an additional route. in case of policy based routing setup a route to the reverse source, as destination.
Small correction to some comments in here.
Routes to individual SSL-VPN users are injected directly into the kernel/FIB, they aren’t visible in get router info routing-table all.
get router info kernel
[…]
tab=254 vf=0 scope=0 type=1 proto=18 prio=10 0.0.0.0/0.0.0.0/0->10.212.134.200/29 pref=0.0.0.0 gwy=0.0.0.0 dev=17(ssl.root)
This is normally done automatically, so the question why it’s failing for you remains unanswered.
Have you checked live SSL-VPN debug? It does have a line about assigning an IP to the user, maybe it will spit out some useful error?
Thanks. VPN client (forticlient) has good routes back to fortigate. I can see the traffic on the doorstop of the firewall. For fun I tried full tunnel, same result. FG saying “reverse path check fail”
Not using policy based routing.
id=20085 trace_id=2251 func=print_pkt_detail line=5727 msg="vd-root:0 received a packet(proto=17, 10.212.134.200:49827->172.16.0.7:53) from ssl.root. "
id=20085 trace_id=2251 func=init_ip_session_common line=5898 msg=“allocate a new session-15457d54”
id=20085 trace_id=2251 func=iprope_dnat_check line=5038 msg=“in-[ssl.root], out-”
id=20085 trace_id=2251 func=iprope_dnat_tree_check line=830 msg=“len=0”
id=20085 trace_id=2251 func=iprope_dnat_check line=5051 msg=“result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000”
id=20085 trace_id=2251 func=ip_route_input_slow line=2264 msg=“reverse path check fail, drop”
naw that’s not it. That’s a dial-up VPN w/ no static routes on the client. I have rfc1918 routes that point back to the firewall.
SSLN VPN Pool
get router info routing-table details 10.212.134.200
Routing table for VRF=0
Routing entry for 10.0.0.0/8
Known via "static", distance 10, metric 0, best
* 10.1.199.1, via sw1 distance 0
Destination
get router info routing-table details 172.16.0.7
Routing table for VRF=0
Routing entry for 172.16.0.0/12
Known via "static", distance 10, metric 0, best
* 10.1.199.1, via sw1 distance 0
get router info routing-table details 10.212.134.200
Routing table for VRF=0
Routing entry for 10.0.0.0/8
Known via “static”, distance 10, metric 0, best
- 10.1.199.1, via sw1 distance 0
This is your problem - the firewall thinks 10.212.134.x should be coming from the 10.1.199.1 path, which is why RPF fails. It should show as a directly connected Null route.
Add a blackhole route for 10.212.134.0/24 and see if it still fails
Thank you,
I’ve got to be close.
Here’s the routing info:
get router info routing-table details
10.212.134.200
Routing table for VRF=0
Routing entry for
10.212.134.0/24
Known via “static”, distance 10, metric 0
directly connected, ssl.root inactive distance 0
Best selected route:
Routing entry for
10.0.0.0/8
Known via “static”, distance 10, metric 0, best
*
10.1.199.1, via sw1 distance 0
Still seeing the reverse path check fail, drop
messages. Is that because my blackhole route above is not the “best selected route”?
Thank you,
I’ve got to be close.
Here’s the routing info:
get router info routing-table details 10.212.134.200
Routing table for VRF=0
Routing entry for 10.212.134.0/24
Known via "static", distance 10, metric 0
directly connected, ssl.root inactive distance 0
Best selected route:
Routing entry for 10.0.0.0/8
Known via "static", distance 10, metric 0, best
* 10.1.199.1, via sw1 distance 0
Still seeing the reverse path check fail, drop messages. Is that because my blackhole route above is not the “best selected route”?
I can connect no problem. Just can’t pass traffic. If I do a pcap on the FG, I can see my traffic coming into ssl.root from my VPN IP (10.212.134.200).
No Problem, it’s gone.
auto-tunnel-static-route looks to be enabled.
config vpn ssl settings
(settings) # show full | grep auto-tunnel-static-route
set auto-tunnel-static-route enable
