FortiClient SSL VPN stops at 10% for one user out of 20

VPN
1

The connection stops at 10 % and based on my research, this means the users laptop is were the problem lies.

So far, I have:

- removed / reinstalled the FortiClient.

- downgraded FortiClient to an earlier version.

- deleted/reinstalled all network adaptors

- disabled IPv6

- checked for any traffic hitting the gate - none noted

- tested the users FortiClient with a different username and pw - same issue

- tested the users vpn creds with another computer - OK, works fine.

- disabled user’s MFA

- disabled users firewall and AV

- tested device on a different network

- Ran a capture on Wireshark, the only relevant results I can see relating to the VPN gateway comms:

“538”,“1.979798”,“Users IP”," VPN gateway IP",“TCP”,“66”,“50392 → 54751 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM”

“683”,“2.993174”,“Users IP”,“VPN gateway IP”,“TCP”,“66”,“[TCP Retransmission] 50392 → 54751 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM”

“1082”,“4.997670”,“Users IP”,“VPN gateway IP”,“TCP”,“66”,“[TCP Retransmission] 50392 → 54751 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM”

Any advice on where to look next would be greatly appreciated.

*** EDIT # 2 ***

Problem solved:

When testing the user was Hot spotting from his cell, the phone was using the local Wi-Fi → network instead of the Cell data connection. As soon as we turned off his phone’s Wi-Fi - no problem.

​

​

​

​

​

2

Hello,

I had a similar issue with 10% SSL VPN. User had a public ip address that was in the ISDB Malicious database. I disabled the entry and it work after. I was able to identify the issue with a simple debug flow in CLI.

diag debug reset

diagnose debug flow trace stop

diagnose debug enable

diag debug flow filter sadd

diagnose debug flow show function-name enable

diagnose debug flow trace start 9999

Check if you have inbound blacklist policy to deny traffic coming from Malicious ISDB like spam, tor, ip addresses.

With the debug flow you can identify what policy is denying the traffic.

With this command you can also identify what ISDB is concerned so you can disable the entry :

diagnose internet-service match root 255.255.255.255

To disable the entry
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-Disable-Specific-IP-Addresses-or-IP-Address/ta-p/271410

3

Might be a long shot, but try reducing the MTU size

4

try turning off IPV6 on remote machine, ran into this with certain Cellular hot spots

5

When you removed / reinstalled the Forticlient, did you just do it through Windows? I feel like I had a similar issue and removing the client with the FCRemove tool fixed it:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-download-FortiClient-and-FCRemove-exe-from/ta-p/218955

6

Hey everyone - finally got it sorted.

For some reason the users cell phone was using the local Wi-Fi Network when using the hotspot instead of the Cellular network. I was sure that using Cell Hotspot would disable the Wi-Fi automatically. Not on the newer phones evidently.

The clue was during the tracert and ping, nothing was getting responded to and when checking the public IP address on the Laptop with Hot spot connected - it was the same as the Local network.

Turned off the Cell phone Wi-Fi and everything working OK.

Really appreciate everyone’s help and advice which led me to the solution.

Merry Christmas to one and all.

7

Is there enough IP addresses available in the SSL VPN DHCP pool? The number available is quite low by default.

8

https://blog.vinck.cloud/forticlient-ssl-vpn-challenges/

Here is a quick guide I found. Pretty basic but good troubleshooting for the later percentages.

10% is usually a system side issue. Check if they can ping and nslookup the firewall.

How are your users logging in?

9

You said you deleted/reinstalled network adapters. Have you compared the NIC driver with a known working device? Kind of a long shot but might be worth checking.

10

What internet provider are they using? Ask them if its T-Mobile home.

If it is, that’s your issue and you need to adjust MTU setting on the actual laptop/desktop. Pulled my hair out on that one before. Tmobile home= POS

(Same may apply for Verizon5G gateway)

Have them test by connecting from another location.

Sample issues- https://community.t-mobile.com/coverage-signal-32/vpn-issues-34151

EDIT - To be honest it’s been awhile, so I cannot remember if they couldn’t connect or they COULD connect, but server resources would not respond or respond SUPER slowly (I believe it was the latter) Adjusting mtu via “netsh” solved it.

11

Have you confirmed this is a FortiIssue? Sounds like the initial packets aren’t even making it to the FortiGate so it’s not a FortiGate issue.

Do you know if it’s actually a FortiClient issue?

Try connecting to the IP and port for the FortiGate VPN service using telnet or netcat or other tool. Does it connect? If not, it’s NOT a FortiClient issue…

12

There is KB showing the correspondance between percentage and possible root causes : https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Possible-reasons-for-FortiClient-SSL-VPN/ta-p/211965

13

Silly you’ve spent this much time on this issue. Reimage his laptop and move on

14

I’m not sure anyone pointed this out yet but if you use any port other than 443 for the sslvpn listener, you need to make sure you customize the port to match in FortiClient

15

This happens to me when my internet is not strong enough.

16

What do the firewall logs say?

17

So 10% is normally a connectivity problem.

Can the user get to the web portal and login?

18

9 times out of 10 when it stops at 10%, it’s one of two things:

  1. You’re using a self signed or untrusted cert and the client is popping up a notification about it to accept or decline the cert. FortiClient is quirky in that it pops this window up BEHIND the main FortiClient screen, so you never see it unless you look for it.
  2. Name resolution or otherwise unable to get to the IP of the gateway.
19

What do the logs say?

20

The Client isn’t hitting the gate at all so no debug traffic is generated for this VPN connection attempt. Everything points to the user’s laptop network connection especially the fact that its stopping at 10% and there are not ACK packets being returned for the session.