FortiClient VPN - Error 6005

[DavidAno]

Hello All,

We just updated our organization to FortiClient 7.2.4.0972 and seem to be having issues.

A little background about our setup:

We have a FortiGate 200F running FortiOS 7.0.13

We use Single Sign-On integrated with Azure

We have a valid SSL certificate that is assigned to the VPN and SSO configurations

We were previously running FortiClient 7.0.2.090 and SAML login was working fine

After installing FortiClient 7.2.4.0972 it seems that some computers are unable to connect to the VPN.  If you click the Sign-in button the window to sign into azure pops up, the authentication works fine, and then the window closes.   Immediately the VPN begins connecting, and then shows disconnecting.  A notification pops up saying that the FortiClient connection is down.  FortiClient shows an error 6005 and a warning about a certificate error.

I looked through all of the FortiClient logs on the computer in C:\ProgramFiles and Appdata, but don't see anything noteworthy that would indicate where the issue is.

This is happening for multiple computers, but not all computers.  I know all of the configuration is working because several devices are able to connect without issue using SAML.  Trying to find the common link between the computers that are not working.   

I did a debug on the firewall and this was the results

[310:root:d696]allocSSLConn:307 sconn 0x7f7d8cd5b900 (0:root)

[310:root:d696]SSL state:before SSL initialization (REMOTE IP)

[310:root:d696]SSL state:before SSL initialization (REMOTE IP)

[310:root:d696]got SNI server name: DOMAIN NAME realm (null)

[310:root:d696]client cert requirement: no

[310:root:d696]SSL state:SSLv3/TLS read client hello (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write server hello (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write certificate (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write key exchange (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write server done (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write server done:system lib(REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write server done (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS read client key exchange (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS read change cipher spec (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS read finished (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write session ticket (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write change cipher spec (REMOTE IP)

[310:root:d696]SSL state:SSLv3/TLS write finished (REMOTE IP)

[310:root:d696]SSL state:SSL negotiation finished successfully (REMOTE IP)

[310:root:d696]SSL established: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384

[310:root:d696]req: /remote/saml/start

[310:root:d696]rmt_web_auth_info_parser_common:492 no session id in auth info

[310:root:d696]rmt_web_get_access_cache:841 invalid cache, ret=4103

[310:root:d696]sslvpn_auth_check_usrgroup:2978 forming user/group list from policy.

[310:root:d696]sslvpn_auth_check_usrgroup:3024 got user (0) group (2:0).

[310:root:d696]sslvpn_validate_user_group_list:1890 validating with SSL VPN authentication rules (2), realm ((null)).

[310:root:d696]sslvpn_validate_user_group_list:1975 checking rule 1 cipher.

[310:root:d696]sslvpn_validate_user_group_list:1983 checking rule 1 realm.

[310:root:d696]sslvpn_validate_user_group_list:1994 checking rule 1 source intf.

[310:root:d696]sslvpn_validate_user_group_list:2033 checking rule 1 vd source intf.

[310:root:d696]sslvpn_validate_user_group_list:2526 rule 1 done, got user (0:0) group (1:0) peer group (0).

[310:root:d696]sslvpn_validate_user_group_list:1975 checking rule 2 cipher.

[310:root:d696]sslvpn_validate_user_group_list:1983 checking rule 2 realm.

[310:root:d696]sslvpn_validate_user_group_list:1994 checking rule 2 source intf.

[310:root:d696]sslvpn_validate_user_group_list:2526 rule 2 done, got user (0:0) group (2:0) peer group (0).

[310:root:d696]sslvpn_validate_user_group_list:2534 got user (0:0) group (2:0) peer group (0).

[310:root:d696]sslvpn_validate_user_group_list:2876 got user (0:0), group (2:0) peer group (0).

[310:root:d696]sslvpn_update_user_group_list:1793 got user (0:0), group (2:0), peer group (0) after update.

[310:root:d696][fsv_found_saml_server_name_from_auth_lst:123] Found SAML server [azure] in group [Azure VPN Users]

[310:root:d696]Timeout for connection 0x7f7d8cd5b900.

[310:root:d696]Destroy sconn 0x7f7d8cd5b900, connSize=4. (root)

[310:root:d696]SSL state:warning close notify (REMOTE IP)

[312:root:d696]allocSSLConn:307 sconn 0x7f7d8cd56500 (0:root)

[312:root:d696]SSL state:before SSL initialization (REMOTE IP)

[312:root:d696]SSL state:before SSL initialization:DH lib(REMOTE IP)

[312:root:d696]SSL_accept failed, 5:(null)

[312:root:d696]Destroy sconn 0x7f7d8cd56500, connSize=1. (root)

[306:root:d696]allocSSLConn:307 sconn 0x7f7d8c12be00 (0:root)

[306:root:d696]SSL state:before SSL initialization (REMOTE IP)

[306:root:d696]SSL state:before SSL initialization:DH lib(REMOTE IP)

[306:root:d696]SSL_accept failed, 5:(null)

[306:root:d696]Destroy sconn 0x7f7d8c12be00, connSize=5. (root)

[307:root:d697]allocSSLConn:307 sconn 0x7f7d8cd56500 (0:root)

[307:root:d697]SSL state:before SSL initialization (REMOTE IP)

[307:root:d697]SSL state:before SSL initialization:DH lib(REMOTE IP)

[307:root:d697]SSL_accept failed, 5:(null)

[307:root:d697]Destroy sconn 0x7f7d8cd56500, connSize=2. (root)

[AndrewF]

I'm also having the exact same issue:

Installed FortiClient 7.2.4 and configured as below:
domain name entered for "Remote Gateway"
customised port 443 ticked 
"Enable single sign on (SSO) for VPN tunnel" ticket
client certificate "None"

Attempted to connect which instantly fails and log shows the following message:

"The server you want to connect to requests identification, please choose a certificate and try again. (-6005)"

We do not use certificates for our VPN clients. As per others suggestions I deleted personal certificates, in particular the Adobe certs

After this was able to successfully connect to the VPN.

Note. Prior to doing the above I reinstalled forticlient 7.2.2 and had no issues and the personal certificates had not been removed at this point.

We have also been able to reproduce this issue on multiple computers with the work around to remove personal certificates.

This issue has also affected 7.2.3. Hopefully this helps to show this is affecting multiple Fortinet customers and Fortinet can start to look into this issue with the 7.2.4 version of Forticlient.

[LeoLi]

The workaround is to remove any CA in current user store for FCT 7.2.4 GA

It's true that FCT 7.2.3 GA doesn't have the issue.

As usual, expect end user to import CA to Trusted Root CA Authorities, rather than in current user store, but FCT should still be able to handle this.

[AndrewF]

Thanks Leo. Agree the cert is in the wrong place but this seems to have been done by Adobe, nothing that we have manually imported. This is evident given the amount of Fortinet customer reporting the same issue.
Also, have tested with 7.2.3 and I can confirm the issue is present in this version

Will this issue be fixed in the next FCT version?

[LeoLi]

Yes. it will be fixed in next FCT version. 
Please check this issue with Tac team, as TAC team should have updated and best workaround (to me, such as adding a certificate filter for the VPN tunnel to filter out all certificates in current user store and local computer) about the issue temporarily. 

Thank you ALL.

[AndrewF]

Thats great news, thanks very much for your help.

[Userwithname]

When 7.3.x version will be expected? Do have the same isseu with SAML and IDP with Azure.

Rolling back the previous version will result in updating the client automatic to newest version. 

[ethandaviss03]

Testing on different computers may reveal common factors. Consider rolling back or reinstalling FortiClient versions.

[AndrewF]

Yes, I've done those things and even included that info in my original post.

[ustechsupporta]

I can confirm that this behavior is appearing in our environment too.  Adobe + FortiClient 7.2.4 = No good.

A specific machine began reporting this behavior.  I could not get it to connect to the VPN to save my life. 

• Same User Account + ForiClient7.2.4 + Win11 PC1 with no Adobe = Connect.   
• Same User Account + FortiClient 7.2.4 +  Win11 PC2 Adobe = No Good.
• Same User Account + FortiClient 7.2.2 + Win11 PC2 Adobe = Connect

Obviously some conflict between how Adobe is storing their certificate + whatever FortiClient is reading/matching.  Our configuration uses NO client side certicate.  So it is interesting that FortiClient is trying to match something.

[ustechsupporta]

Can confirm that removing the 8x Adobe CA certificates that show up under Certificates - Current User  > Personal > Certificates - resolves the issue.