FortiClient VPN stops at 48% with warning -7200

[sidp]

Hi,

Our users keep having problems logging in with Forticlient VPN only.
It happens very often that Forticlient stops at 48% and issues the warning -7200. Sometimes you have to repeat the login process 3-7 times and then the client asks for the Fortitoken and can then log in successfully.

FortiOS v6.4.15

We are using LDAP authentication with Fortitoken.

It doesn't matter whether I set username-sensitivity to disable or leave it at default enable.

Does anyone know the problem and can help?

[326:root:d3a]allocSSLConn:298 sconn 0x7f268edacd00 (0:root)
[326:root:d3a]SSL state:before SSL initialization (77.239.xy.xyx)
[326:root:d3a]SSL state:before SSL initialization:DH lib(77.239.xy.xyx)
[326:root:d3a]SSL_accept failed, 5:(null)
[326:root:d3a]Destroy sconn 0x7f268edacd00, connSize=1. (root)
[327:root:d3c]allocSSLConn:298 sconn 0x7f268edac800 (0:root)
[327:root:d3c]SSL state:before SSL initialization (77.239.xy.xyx)
[327:root:d3c]SSL state:before SSL initialization (77.239.xy.xyx)
[327:root:d3c]got SNI server name: sslvpn.url.com realm (null)
[327:root:d3c]client cert requirement: no
[327:root:d3c]SSL state:SSLv3/TLS read client hello (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write server hello (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write certificate (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write key exchange (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write server done (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write server done:system lib(77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write server done (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS read client key exchange (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS read change cipher spec (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS read finished (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write session ticket (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write change cipher spec (77.239.xy.xyx)
[327:root:d3c]SSL state:SSLv3/TLS write finished (77.239.xy.xyx)
[327:root:d3c]SSL state:SSL negotiation finished successfully (77.239.xy.xyx)
[327:root:d3c]SSL established: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
[327:root:d3c]req: /remote/info
[327:root:d3c]capability flags: 0xdf
[327:root:d3c]req: /remote/login?realm=mts
[327:root:d3c]rmt_web_auth_info_parser_common:465 no session id in auth info
[327:root:d3c]rmt_web_get_access_cache:808 invalid cache, ret=4103
[327:root:d3c]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[327:root:d3c]get_cust_page:127 saml_info 0
[327:root:d3c]req: /remote/logincheck
[327:root:d3c]rmt_web_auth_info_parser_common:465 no session id in auth info
[327:root:d3c]rmt_web_access_check:727 access failed, uri=[/remote/logincheck],ret=4103,
[327:root:d3c]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[327:root:d3c]rmt_logincheck_cb_handler:1255 user 'max' has a matched local entry.
[327:root:d3c]sslvpn_auth_check_usrgroup:2719 forming user/group list from policy.
[327:root:d3c]sslvpn_auth_check_usrgroup:2757 got user (0) group (3:0).
[327:root:d3c]sslvpn_validate_user_group_list:1843 validating with SSL VPN authentication rules (3), realm (mts).
[327:root:d3c]sslvpn_validate_user_group_list:1928 checking rule 2 cipher.
[327:root:d3c]sslvpn_validate_user_group_list:1936 checking rule 2 realm.
[327:root:d3c]sslvpn_validate_user_group_list:1947 checking rule 2 source intf.
[327:root:d3c]sslvpn_validate_user_group_list:1986 checking rule 2 vd source intf.
[327:root:d3c]sslvpn_validate_user_group_list:2267 rule 2 done, got user (0:0) group (1:0) peer group (0).
[327:root:d3c]sslvpn_validate_user_group_list:1928 checking rule 3 cipher.
[327:root:d3c]sslvpn_validate_user_group_list:1936 checking rule 3 realm.
[327:root:d3c]sslvpn_validate_user_group_list:1928 checking rule 4 cipher.
[327:root:d3c]sslvpn_validate_user_group_list:1936 checking rule 4 realm.
[327:root:d3c]sslvpn_validate_user_group_list:2275 got user (0:0) group (1:0) peer group (0).
[327:root:d3c]sslvpn_validate_user_group_list:2618 got user (0:0), group (1:0) peer group (0).
[327:root:d3c]sslvpn_update_user_group_list:1750 got user (0:0), group (1:0), peer group (0) after update.
[327:root:d3c]two factor check for max: off
[327:root:d3c]sslvpn_authenticate_user:167 authenticate user: [max]
[327:root:d3c]sslvpn_authenticate_user:174 create fam state
[327:root:d3c][fam_auth_send_req_internal:425] Groups sent to FNBAM:
[327:root:d3c]group_desc[0].grpname = ldap_dl-fg-sslvpn-realm-mts
[327:root:d3c][fam_auth_send_req_internal:437] FNBAM opt = 0X200420
[327:root:d3c]fam_auth_send_req_internal:513 fnbam_auth return: 4
[327:root:d3c]fam_auth_proc_resp:1287 fnbam_auth_update_result return: 3
[327:root:d3c][fam_auth_proc_resp:1385] Authenticated groups (1) by FNBAM:
[327:root:d3c]Received: auth_rsp_data.grp_list[0] = 3054238368
[327:root:d3c]login_failed:391 user[max],auth_type=1 failed [sslvpn_login_no_matching_policy]

[fricci_FTNT]

Hi @sidp ,

Thank you for those outputs, I have not spotted any anomaly.
Please let us know if you still experience the issue while the LDAP server IP address is set rather than the name.

Best regards,

[FortiNole]

Following along with this one.  We are having the exact same issue.  

[Pittstate]

We had this exact same error occurring under 7.0.14, but I ended up closing out the ticket as the problem was intermittent and was never able to get a good capture. But I will post what FN support last said to do as troubleshooting steps. Some of which has been mentioned.

But one thing you might try is disabling IPv6 on the client side if it is not necessary for your environment. Some documentation I ran across that I can not find now, mentioned there could be an issue with that and the ssl-vpn client under certain circumstances.

Anyway, below is the next step path that FN support was going to have me follow:

"As part of further debug capture, I'll need commands to also capture as much information for the FMDB (diag de app fndbamd ????), does a -1 flag on the end capture all debug info for that process? Also is a -1 flag sufficient to capture all debug info for the sslvpn application?
To obtain the complete logs, we require both FNABN and SSL debugs. Packet capture can also provide valuable information.

# diagnose debug application fnbamd -1
# diagnose vpn ssl debug-filter src-addr4 x.x.x.x ------------->Public IP of the client
# diagnose debug application sslvpn -1
# diagnose debug console timestamp enable
# diagnose debug enable
# diagnose sniffer packet any "host [radius-srv-ip] and port (1812 or 1813)" 6 0 l
# diagnose sniffer packet any "host x.x.x.x and port 443" 6 0 l ------------->Public IP of the client

We can also enable debug login on the forticleint

https://community.fortinet.com/t5/FortiClient/Technical-Tip-How-to-enable-debug-log-in-FortiClient/t...
https://community.fortinet.com/t5/FortiClient/Technical-Tip-How-to-generate-and-export-Debug-logs-fr...

We need to isolate whether the issue is occurring on the FGT or on the FortiClient. Therefore, could you perform the test on SSL VPN web mode and inform us of the results? If the issue lies with FortiClient, we'll need to troubleshoot it from the FortiClient perspective."