I cannot ping any machine in the VPN. I suspect the route information added is incorrect as I see the message "VPN FortiSslvpn: 8476: failed to add route for c0a80200:ffffff00, error code:5010" in the forti log.
I'm seeing similar results with my VPN clients. I recently took over the management of our Fortigate firewall/routers, in the course of upgrading them from Fortigate 60Cs to 61E. Some of our users have been complaining for years about intermittent problems with their VPNs. I copied the configurations for Ciscoclient (IPsec), FortiClient (also IPsec) and SSL VPNs from the old routers to the new, and the problems persisted, if they have not gotten worse, and I've been looking into it.
The IPsec VPNs seem to be working well now (discovered and removed what appeared to be a completely unnecessary policy route to a customer's system that made that particular system inaccessible, which *might* have been the only problem with IPsec) but the SSL VPNs still have major difficulties.
A few days ago, I decided the SSL problems might originate with routing problems and had several users send me their routing tables. (This was like pulling teeth. The users are all professional programmers, some with a fair amount of network applications experience, so they all have their own theories about what might be wrong, and only provide me with data that supports those theories, not everything I ask for.)
After several days, I got some of them to send me the actual output of Windows "route print" and it looks a lot like your output.
In particular, the default route is via the user's assigned IP address, with the gateway listed as that address plus 1, which is just another address in the SSL pool, and NOT a router! If the user's system is actually trying to route packets to that address, they would go nowhere fast (or slowly), so no wonder they have connectivity issues. (Users on Linux and Mac clients seem to have much fewer difficulties.) What is weird is that they can connect to anything at all, since their default router, much of the time, doesn't exist.
Possibly, all that matters is that they send everything over the SSL tunnel, and not what they think is the router at the other end.
Yesterday, still lacking proper feedback (including copies of their routing table when everything appears to be working okay, which I also asked for), I went back to square one of the SSL VPN configuration, and walked through the cookbook. The one significant difference I noticed was the Fortinet cookbook says to enable NAT on the SSL VPN firewall policy. It was not enabled previously. Today, one of the users reports it is working (though the performance is spotty) and thinks the problem is solved. I'm not so sure. She sent me the output of "route print" (Windows 10, I think) and it still shows the bogus default gateway.
BTW, the routing table from a FortiClient user using IPsec also shows a bogus gateway address once again the address supplied to the user plus one, but in a different address pool. The IPsec routing table also shows a route to our LAN subnet, which is missing from the SSL routing table. This configuration seems to work, despite the bogus gateway. Our real gateway and the pools for SSL clients and IPsec clients are all in the LAN subnet.
Maybe by enabling NAT in the firewall policy, the SSL tunnel interface is doing all the right things now, and the windows routing table is basically irrelevant. BTW, I made sure split routing is disabled, but it always has been.
I've made other changes over the last week, trying to get things to work, some with slight effect and some with no obvious effect, which might be causing the performance issues. I'll need to go back over the changes one-by-one to see which make a difference either positive or negative. in particular, I enabled "route-source-interface" in the "vpn ssl settings", which seems (maybe) to have made things much better for a user using the FortiClient on Linux, but had no obvious effect on the Windows users. I have no real understanding of what this setting does, and the documentation is as clear as mud.
Anyway, I see in almost exactly 2 years, you haven't gotten a response. Do your SSL VPNs work? Have you enabled NAT in the firewall rule? If so, and it still isn't working, I would try "route-source-interface" and the next possibility on my list, "auto-tunnel-static-route", which is equally obscure. The only reason I tried (or am considering trying) these options is they apply to SSL VPNs and seem to have some effect on routing.
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.