Title says it all.
I have a user trying to connect via VPN, after providing the credentials everything goes smoothly up until 98%, the client gets stuck for a minute then goes back to asking for credentials, another minute and it seems to connect, but no inbound traffic is detected and it doesn’t really work.
Same user on a different pc works fine, while users that work don’t on the affected PC.
What could it be? I tryed a bunch of staff from the forums but without success.
I’ve seen this when clients are traversing ipv6 networks. Disable their ipv6, reboot, test… In my network’s case, users were using their company phone for hotspot, and if they were on T-Mobile it would hang at 98%. Disable ipv6 on their wifi adapter and boom, successful connection. I presume a shitty ipv6 to ipv4 translation is to blame…
Reboot your router if this is a home network. I’ve had many annoying calls from users about the same kind of thing. From my own personal experience with this, having double-NAT on my older home network led to this type of inconsistent behavior (sometimes I could connect, sometimes not). Google Mesh with Family Control implements NAT on the wireless pucks, and my firewall obviously introduced NAT as well. Once I gave up Family Control and reverted to plain old access points, VPN connected beyond 98% consistently.
1- Backup your FortiClient Config and then edit it by notepad.
<prefer_sslvpn_dns>1</prefer_sslvpn_dns>change it to
<prefer_sslvpn_dns>0</prefer_sslvpn_dns>
When this setting is 0, the custom DNS server from SSL VPN is not added
to the physical interface. When this setting is 1, the custom DNS server
from SSL VPN is prepended to the physical interface.
After changing the value above save the file and restore it to the FortiClient.
the reason why the Forticlient sometimes got interrupted while it tries to resolve the remote gateway especially if you are using FQDN for the remote gateway and internal DNS for SSLVPN.
once the FortiClient got connected it will get propagate the DNS that is configured on the SSL-VPN config to all local interfaces in the local machine, if you are using internal DNS then once there is a network interruption for a few seconds the fortiClient will try to re-connect while he is trying to resolve the FQDN with the local DNS from the SSLVPN config which at this stage won’t work since you are not connected, the only way to disable this option is what I have mentioned above.
2 Check the “Do not Warn Invalid Server Certificate”.
Please let me know if this helps you.
here you can find all the parameters of the XML file of the FortiClient Profile.
10% – Local Network/PC issue
31% – Certificate not trusted, warning sometimes hidden in background (move window)
40% – Application or the Fortigate causing the error, occasionally caused by the local machines/network setup
45% – MultiFactor Authentication
80% – Username/Password issue ; or trying to connect to wrong port number
98% – corruption of services/often resolved by reinstalling the client on the laptop.
A mi me pasa que al arrancar o intentar conectarme no ocurre nada, como si quisiera entablar conexion pero no ocurre luego si intento desconectar no pasa nada tengo que finalmente cerrar la aplicacion para poder desconectarme lo raro es que no me da algun error ni señales de que algo este mal, cambie dns, quite la conexion IPv6, desinstale y reinstale el programa variadas veces con el mismo problema.
agradeceria su ayuda o comentarios todo es valido.
I Found this nice article a while back and still holds true.
98% – hopefully you are not getting stuck at this point… this problem is
most likely caused by a corrupted FortiClient installation and/or OS
problems. This can probably be solved by reinstalling the FortiClient
software on the computer.
I encountered this problem with a user two months ago. He was able to connect, but no inbound traffic, just outbound traffic. Also, the FortiClient indicated that the client had an IP address but if we check with IPCONFIG, it was an APIPA address. When I checked the SSL VPN connections into the Fortigate, it indicated that the user was connected.
The only way I found to temporarily fix the problem was to restart the SSL VPN service directly in the Fortigate CLI. After several tests, we simply reinstalled the computer because the problem seemed to come from the OS itself.
Command to check SSL VPN active connection get vpn ssl monitor
Command to kill the SSL VPN connection fnsysctl killall sslvpnd
I’m often block at 98% when I’m in LTE or sharing from my phone to my laptop and/or ipv6 is enforced by my provider. If I disable ipv6 on my device I’m connected and the vpn works.
I’m sure our corp FW has no IPv6 but not sure why it’s blocked
In my environment when I see this, there’s been 2 resolutions… 1. reboot the computer or 2. login to the vpn with different credentials, allow telemetry to sync, disconnect, and have the user log back in.
Since you’ve already re-installed several times, this probably won’t be helpful, but here’s a guide for the potential reasons for failure at different percentages.
- Issues at this stage usually occurs due to a corrupted installation of FortiClient or due to OS problems.
- Reinstall the FortiClient software on the system.
- This may also occur when attempting to negotiate SSL VPN with the free version of FortiClient.
Are you using the free version? The last line there kinda sounds like Fortinet saying if you want it to work properly, you gotta pay the protection money.