Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
New Contributor

FortiClient VPN adds incorrect or wrong route to route table



I am using Windows 10 and FortiClient version When I connect the VPN, it shows it is connected successfully.


Below is the route table information:

PS C:\WINDOWS\system32> route print =========================================================================== Interface List f4 bb 80 3c ed ......Realtek PCIe FE Family Controller  20...0c 8b fd f3 5c f6 ......Microsoft Wi-Fi Direct Virtual Adapter  64...........................fortissl  10...00 09 0f fe 00 01 ......Fortinet Virtual Ethernet Adapter (NDIS 6.30)  14...0c 8b fd f3 5c f5 ......Intel(R) Wireless-N 7260   1...........................Software Loopback Interface 1 ===========================================================================

IPv4 Route Table =========================================================================== Active Routes: Network Destination        Netmask          Gateway       Interface  Metric      25         On-link    266         On-link    306         On-link    306         On-link    306         On-link    281         On-link    281         On-link    281     10     25         On-link    306         On-link    281         On-link    266         On-link    306         On-link    281         On-link    266 =========================================================================== Persistent Routes:   None

IPv6 Route Table =========================================================================== Active Routes:  If Metric Network Destination      Gateway   1    306 ::1/128                  On-link   1    306 ff00::/8                 On-link =========================================================================== Persistent Routes:   None PS C:\WINDOWS\system32>


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 have attached the log file.


Please help me, quick help is appreciated.

Thanks in advance.




New Contributor

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.

I'll update if I discover more.






Esteemed Contributor III

The real question is how the tunnel-mode vpn setup?  Also  are you sure MS-firewall is disabled ? And the vpn pool has a route in the  route table ?



config router static

    edit 488

        set dst

        set device "ssl.root"



config vpn ssl web portal

    edit "full-access"

        set tunnel-mode enable

        set web-mode enable

        set ip-pools "POOLVPN1"

        set page-layout double-column








Top Kudoed Authors