Incorrect routing table entry when SSL VPN is establised
I have a situation affecting some Dell Latitude Laptops (54xx series).
When the VPN is established, there is an incorrect routing entry in the Windows 10 table for our LAN resources where the Gateway points to the IP address of the users home router rather than the VPN interface IP.
Manually deleting the route fixes the issue but that requires elevated privileges so not practical.
Ticket officially logged but just wondering if anyone has experienced this before?
The only way around is to create some sort of windows scheduled task that will run the delete route command with elevated permissions.
The problem I am having with this is to capture the right trigger as the VPN is established, either in event viewer or some process running in Task Manager.
Can anyone help with identifying any of the above as well?
I can't say that I've ever come across such an issue before - I'm sometimes using a Dell Latitude (though 74xx series) myself, with Windows 10 and FortiClient 7.0.2, and not having any issues.
Are you using split-tunneling? I'm not; my default route is through VPN when that's up and running (with metric 1 - the local WiFi default route is metric 50), and traffic is being routed exactly as intended.
+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
SSL-VPN Portal Split tunneling>>>Enabled Based on Policy DestinationDNS Split Tunneling>>>DNS Split Tunneling The FortiClient network driver will intercept DNS requests; if they match the split-dns listed, the DNS request will go across the tunnel and be resolved by the specified DNS servers.
It works well with me.
Take into consideration that FortiClient gets the configuration during it connects. If you do changes disconnect and connect again.
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.