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

FortiClient VPN adds incorrect or wrong route to route table

Hi,

 

I am using Windows 10 and FortiClient version 5.4.0.0780. 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   9...ec 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           0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.4     25    10.212.135.200  255.255.255.255         On-link    10.212.135.200    266         127.0.0.0        255.0.0.0         On-link         127.0.0.1    306         127.0.0.1  255.255.255.255         On-link         127.0.0.1    306   127.255.255.255  255.255.255.255         On-link         127.0.0.1    306       192.168.1.0    255.255.255.0         On-link       192.168.1.4    281       192.168.1.4  255.255.255.255         On-link       192.168.1.4    281     192.168.1.255  255.255.255.255         On-link       192.168.1.4    281       192.168.2.0    255.255.255.0   10.212.135.201   10.212.135.200     10     196.12.42.130  255.255.255.255      192.168.1.1      192.168.1.4     25         224.0.0.0        240.0.0.0         On-link         127.0.0.1    306         224.0.0.0        240.0.0.0         On-link       192.168.1.4    281         224.0.0.0        240.0.0.0         On-link    10.212.135.200    266   255.255.255.255  255.255.255.255         On-link         127.0.0.1    306   255.255.255.255  255.255.255.255         On-link       192.168.1.4    281   255.255.255.255  255.255.255.255         On-link    10.212.135.200    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.

 

Regards,

Arvind.

3 REPLIES 3
John_Santos
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.

 

 

 

 

 

emnoc
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 10.2.1.0 255.255.255.0

        set device "ssl.root"

    next

 

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

    next

end

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Umer221
Staff
Staff
Labels
Top Kudoed Authors