ERROR: SSL_connect: error:0A000126:SSL routines::unexpected eof while reading, Error happen randomly about openfortivpn

[DimitriPapadopoulos]

I fully agree after rereading the initial post and the new information. I initially thought this is an internal OpenSSL issue. Actually the remote server abruptly shuts down the connection, because it doesn't like something. We need to identify what the server doesn't like.

[DimitriPapadopoulos]

Please check with a newer version of openfortivpn. Version 1.17.1 was released back in 2021.

[leompxp]

Hi @DimitriPapadopoulos,
Thank you for your answer

The version 1.17.1-1build1 is the latest version on ubuntu 22.04 in the universe repository and here it does works sometimes,
In my thread I am mostly talking about the version 1.21.0-2build2 on ubuntu 24.04LTS in the noble universe repository where it does not works

[DimitriPapadopoulos]

Perhaps the ciphers supported by the VPN gateway are obsolete and have been disabled in Ubuntu 24.04. What is the version of FortiOS on your Fortigate 100E? Start by trying --insecure-ssl --seclevel-1.

Try a direct OpenSSL connection to the server, the result might give some insight:

$ echo -n | openssl s_client -connect X.X.X.X:443

As for clients, to find supported ciphers:

$ openssl ciphers

[leompxp]

I don't think it is a cipher problem,

Using --insecure-ssl --seclevel-1 give the same inconsistent output, sometimes it works, sometimes it don't with the EOL SSL error.

In my initial message we can see that the cipher negociated during the TLS handshake is a strong and supported cipher by both the client and the fortigate : SSL established: TLSv1.3 TLS_AES_256_GCM_SHA384. So anyway, even if weak cipher were supported, the cipher negociate is not an obsolete one

On the fortigate side we enable only strong-crypto which enable strong cipher for TLS 1.2 and TLS 1.3

Here the results of the command :

$ echo -n | openssl s_client -connect X.X.X.X:443

[....]
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, secp384r1, 384 bits
---
SSL handshake has read 4110 bytes and written 761 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

$ openssl ciphers
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:AES256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:AES128-GCM-SHA256:PSK-AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:AES256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:AES128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA

[leompxp]

To support my point, this morning a colleague ran the command five times with errors, rebooted his machine, then had the error again after the reboot, and the second time it worked.

Also I don't know if this could be a problem with the pkcs11 devices support but when it fail, sometimes, it takes longer (about 15 to 45 seconds) to open the token.

and the error pop almost after reading the token.

But it works most of the time, so I'm not convinced that the code that reads the token could be inconsistent, as it is very straightforward.

[leompxp]

I don't entirely read the source code but I feel like you their is something that causing abruptly shuts down the connection.

I feel like this is on the client side because it is openfortivpn that send the GET /remote/logout, right after sending the crentials instead of the GET /remote/logincheck.

But maybe, the server send to the client that it will not continue anyway and so the openfortivpn try to gracefully shutdown the connection by sending /remote/logout.

But I could not capture anything between theSSL established: TLSv1.3 TLS_AES_256_GCM_SHA384 and the /remote/logout. These two log follow each other.