Openfortivpn on Ubuntu 20.04

[mxmrlt]

Hi everyone.

Since migration to Ubuntu 20.04 from Ubuntu 19.04 I can connect but DNS config isn't done.

Here's what I run:
sudo openfortivpn x.x.x.x:10443 -u USER -p PASSWORD --set-routes=1 --set-dns=1 --pppd-use-peerdns=1 --trusted-cert XXXXXXXXXXXXXXXXXXX

This issue is that resolv.conf has permission issue even when ran with sudo => Could not open /etc/resolv.conf (Permission denied).

And here's what's in the console
WARN: You should not pass the password on the command line. Type it interactively or use a config file instead.
INFO: Connected to gateway.
INFO: Authenticated.
INFO: Remote gateway has allocated a VPN.
INFO: Got addresses: [x.x.x.x], ns [172.17.100.2, 172.17.100.1]
INFO: Negotiation complete.
INFO: Negotiation complete.
INFO: Interface ppp0 is UP.
INFO: Setting new routes...
WARN: Route to gateway exists already.
WARN: Route to gateway exists already.
INFO: Adding VPN nameservers...
WARN: Could not open /etc/resolv.conf (Permission denied).
INFO: Tunnel is up and running.

Could someone help me?

Thank you.

[DimitriPapadopoulos]

First of all, it's probably a bad idea to have both --set-dns=1 and --pppd-use-peerdns=1. Either let openfortivpn attempt to handle DNS (the default in recent versions):

--set-dns=1 --pppd-use-peerdns=0

or ask pppd:

--set-dns=0 --pppd-use-peerdns=1

Then are you building openfortivpn from sources or installing the DEB package? I suspect that the DEB package is outdated on Ubuntu:

$ /usr/bin/openfortivpn --version
1.12.0
$ 

[DimitriPapadopoulos]

But then this error is not tied to a specific version of openfortivpn:

WARN: Could not open /etc/resolv.conf (Permission denied).

It works for me just fine on Ubuntu 20.04. However I have installed resolvconf which shouldn't be a requirement:

$ ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 29 Apr 18 10:57 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
$ 

Let me check without resolvconf or openresolve.

[DimitriPapadopoulos]

1. About the warning: I cannot reproduce it after removing resolvconf:

   $ ls -l /etc/resolv.conf 
   lrwxrwxrwx 1 root root 39 Apr 27 12:56 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
   $ 
   $ ls -l /run/systemd/resolve/stub-resolv.conf
   -rw-r--r-- 1 systemd-resolve systemd-resolve 707 Apr 27 13:13 /run/systemd/resolve/stub-resolv.conf
   $ 
   

   What is the output of the above command on your computer? Also what is the output of:

   dpkg -l | grep resolv
   

2. On the other hand this does not mean the new DNS servers are properly taken into account. Let me have a look at that too. But first I'd like to take issue 1 out of the way.

[mxmrlt]

Thank you for your quick answer.
Actually I use Snap Openfortivpn version which is vers 1.13.3

$ openfortivpn --version
1.13.3
$ 

When I run:

sudo openfortivpn x.x.x.x:999 -u USER -p PASSWORD --set-routes=1 --set-dns=1 --pppd-use-peerdns=0 --trusted-cert XXXXXXXXXXXXXXXXXXX

I got this in the console:

ARN:   You should not pass the password on the command line. Type it interactively or use a config file instead.
INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
INFO:   Got addresses: [x.x.x.x], ns [0.0.0.0, 0.0.0.0]
INFO:   Negotiation complete.
INFO:   Negotiation complete.
INFO:   Interface ppp0 is UP.
INFO:   Setting new routes...
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
INFO:   Adding VPN nameservers...
WARN:   Could not open /etc/resolv.conf (Permission denied).
INFO:   Tunnel is up and running.

ns [0.0.0.0, 0.0.0.0] #sounds weird
WARN:   Could not open /etc/resolv.conf (Permission denied). #Still

   What is the output of the above command on your computer?

Same as you apparently.

$ ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 37 avril 27 08:44 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
$
$ ls -l /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 720 avril 27 13:28 /run/systemd/resolve/stub-resolv.conf
$ 

output of: dpkg -l | grep resolv

$ dpkg -l | grep resolv
ii  libmaven-resolver-java                     1.4.1-1                                    all          Library to handle Java artifact repositories
$

[mxmrlt]

If I use 1.12.0 from apt install

I've got completely different message

WARN:   You should not pass the password on the command line. Type it interactively or use a config file instead.
ERROR:  SSL_connect: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
You might want to try --insecure-ssl or specify a different --cipher-list
INFO:   Closed connection to gateway.
ERROR:  SSL_connect: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
You might want to try --insecure-ssl or specify a different --cipher-list
INFO:   Could not log out.

[DimitriPapadopoulos]

OK. So you don't have resolvconf or openresolv installed. Let's keep it that way.

I can reproduce the problem with the snap, and it makes sense as the snap's confinement prevents from modifying files in /etc:

WARN:   Could not open /etc/resolv.conf (Permission denied).

I can investigate whether and how the snap confinement problem can be fixed. But please open an issue against the snap, as this is not really an openfortivpn problem:
https://github.com/openfortivpn/snap/issues

Also what's strange is that installing resolvconf fixes the snap problem but installing openresolv doesn't. Rather strange. I'll look into this too if you open an issue against the snap.

To obtain the exact version of openfortivpn, please run:

$ /snap/bin/openfortivpn -v --version
1.13.3
DEBUG:  revision v1.13.3+git37.g144857c
$ 

Finally and most importantly I cannot explain this:

INFO:   Got addresses: [11.0.0.3], ns [0.0.0.0, 0.0.0.0]

This doesn't look like it's specific to the snap. It's as if your VPN appliance weren't sending new DNS servers or search domains anyway. To double-check that, I would need the (sanitized) output of openfortivpn -v -v and especially the config sent by the VPN appliance in XML format. In my case:

$ sudo /snap/bin/openfortivpn -v -v -u xxxxxxx -p xxxxxxxxxxxx xxxxx.xxxx.xx
DEBUG:  openfortivpn 1.13.3
DEBUG:  revision v1.13.3+git37.g144857c
[...]
<?xml version='1.0' encoding='utf-8'?><sslvpn-tunnel ver='2' dtls='1' patch='1'><dtls-config heartbeat-interval='10' heartbeat-fail-count='10' heartbeat-idle-timeout='10' client-hello-timeout='10' /><tunnel-method value='ppp' /><tunnel-method value='tun' /><fos platform='FGT60D' major='6' minor='00' patch='9' build='0335' branch='0335' /><client-config save-password='off' keep-alive='off' auto-connect='off' /><ipv4><dns domain='xxxx.xx xxx.xxxx.xx xxx.xxx' /><dns ip='xxx.xx.xxx.252' /><dns ip='xxx.xx.xxx.202' /><assigned-addr ipv4='10.212.134.200' /></ipv4><idle-timeout val='0' /><auth-timeout val='28800' /></sslvpn-tunnel>
0

DEBUG:  found dns suffix xxxx.xx xxx.xxxx.xx xxx.xx in xml config
DEBUG:  found dns server xxx.xx.xxx.252 in xml config
DEBUG:  found dns server xxx.xx.xxx.202 in xml config
DEBUG:  Establishing the tunnel
[...]
INFO:   Got addresses: [10.212.134.200], ns [xxx.xx.xxx.252, xxx.xx.xxx.202], ns_suffix [xxxx.xx xxx.xxxx.xx xxx.xx]
INFO:   Negotiation complete.
[...]
INFO:   Adding VPN nameservers...
WARN:   Could not open /etc/resolv.conf (Permission denied).
INFO:   Tunnel is up and running.

[DimitriPapadopoulos]

The problem with the DEB package is different and it's not a known issue I'm afraid. It looks like your VPN appliance is using ciphers that are not supported by your OpenSSL by default. Have you tweaked your OpenSSL configuration (/etc/ssl/openssl.cnf)? On my machine:

$ ls -l /etc/ssl/openssl.cnf 
-rw-r--r-- 1 root root 10909 Mar  6 05:08 /etc/ssl/openssl.cnf
$ 
$ sha256sum /etc/ssl/openssl.cnf
f10ba64917b4458fafc1e078c2eb9e6a7602e68fc98c2e9e6df5e1636ae27d6b  /etc/ssl/openssl.cnf
$ 

Also run openfortivpn -v -v. What does the following line from the output look lie in your case?

DEBUG:  Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4

[mxmrlt]

The problem with the DEB package is different and it's not a known issue I'm afraid. It looks like your VPN appliance is using ciphers that are not supported by your OpenSSL by default. Have you tweaked your OpenSSL configuration (/etc/ssl/openssl.cnf)? On my machine:

$ ls -l /etc/ssl/openssl.cnf 
-rw-r--r-- 1 root root 10909 Mar  6 05:08 /etc/ssl/openssl.cnf
$ 
$ sha256sum /etc/ssl/openssl.cnf
f10ba64917b4458fafc1e078c2eb9e6a7602e68fc98c2e9e6df5e1636ae27d6b  /etc/ssl/openssl.cnf
$ 

Also run openfortivpn -v -v. What does the following line from the output look lie in your case?

DEBUG:  Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4

I have not tweaked anything at all. I just installed a fresh new Ubuntu 20.04 on my laptop.

Same as you
DEBUG: Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4

[mxmrlt]

I asked a colleague who is still under Ubuntu 18.04 and Openfortivpn 1.6.x
He doesn't see the line DEBUG: Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4 when running openfortivpn command.
Pretty weird...

[DimitriPapadopoulos]

It looks like there's no XML because the FortiGate appliance doesn't send any:

DEBUG:  Retrieving configuration
DEBUG:  http_send:
GET /remote/fortisslvpn_xml HTTP/1.1
Host: xx.xx.xxx.xx:10443
User-Agent: Mozilla/5.0 SV1
Accept: text/plain
Accept-Encoding: identity
Content-Type: application/x-www-form-urlencoded
Cookie: SVPNCOOKIE=KVjkjzSU+pB1ex6+33/BbLtr1wOX0pYOlj03vzIVqtkeW1bMIeBFOB+65V85/s7t%0aF7uu8yoM3YnobOjvglkdYglFOJ+Fpxzbv+XIvOhVr4yp3u9bIxbhtkci7FzsVgBC%0aJ33Dk+rKJeR0pJFHgyWtDw==%0a
Content-Length: 0


DEBUG:  http_receive:
HTTP/1.1 404 Not Found

The FortiGate appliance returns a 404 error. Are you positive nothing has been changed in the configuration of the FortiGate appliance?

[DimitriPapadopoulos]

The core problem is here:

openfortivpn/src/http.c

Lines 860 to 880 in e59bc21

	int auth_get_config(struct tunnel *tunnel)
	{
	char *buffer;
	int ret;
	ret = http_request(tunnel, "GET", "/remote/fortisslvpn_xml", "", &buffer, NULL);
	if (ret == 1) {
	ret = parse_xml_config(tunnel, buffer);
	free(buffer);
	}
	if (ret == 1)
	return ret;
	ret = http_request(tunnel, "GET", "/remote/fortisslvpn", "", &buffer, NULL);
	if (ret == 1) {
	ret = parse_config(tunnel, buffer);
	free(buffer);
	}
	return ret;
	}

As you can see openfortivpn first sends a /remote/fortisslvpn_xml request for an XML-formatted configuration, which in your case fails with a 404 error. I understand recent Fortigate appliances are able to respond with success (200) to this request. Anyway.
Then openfortivpn sends a /remote/fortisslvpn request for an HTML-formatted configuration, which succeeds with a 200 status code. The HTML response is parsed by parse_config() which clearly has never expected to find DNS servers and search domains in the HTML configuration, only <dest>/<mask> split VPN routes:

openfortivpn/src/http.c

Lines 810 to 857 in e59bc21

	static int parse_config(struct tunnel *tunnel, const char *buffer)
	{
	const char *c, *end;
	buffer = strcasestr(buffer, "NAME=\"text6\"");
	if (!buffer)
	return 1;
	buffer = strcasestr(buffer, "VALUE=\"");
	if (!buffer)
	return 1;
	buffer += 7;
	end = strchr(buffer, '"');
	if (end == NULL || end == buffer) {
	log_info("No split VPN route\n");
	return 1;
	}
	do {
	char dest[16], mask[16];
	c = strchr(buffer, '/');
	if (c == NULL || c >= end || c - buffer > 15) {
	log_warn("Wrong addresses in split VPN route: expected <dest>/<mask>\n");
	return 1;
	}
	memcpy(dest, buffer, c - buffer);
	dest[c - buffer] = '\0';
	buffer = c + 1;
	c = strchr(buffer, ',');
	if (c == NULL || c > end)
	c = end;
	if (c - buffer > 15) {
	log_warn("Wrong addresses in split VPN route: expected <dest>/<mask>\n");
	return 1;
	}
	memcpy(mask, buffer, c - buffer);
	mask[c - buffer] = '\0';
	buffer = c + 1;
	ipv4_add_split_vpn_route(tunnel, dest, mask, NULL);
	} while (c < end && *c == ',');
	return 1;
	}

Therefore this is OK:

INFO:   Got addresses: [11.0.0.3], ns [0.0.0.0, 0.0.0.0]

For this reason it is actually not required to modify /etc/resolv.conf in your case. You should be able to enforce that with:

--set-dns=0 --pppd-use-peerdns=0

Regardless you shouldn't see the Permission issue on /etc/resolv.conf warning. However that's a snap issue and I'll follow up on the issue you've opened here:
openfortivpn#4

[DimitriPapadopoulos]

The only remaining problem here is the one with the openfortivpn 1.12.0 DEB package:

ERROR:  SSL_connect: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
You might want to try --insecure-ssl or specify a different --cipher-list

I really have no clue. @mrbaseman?

[DimitriPapadopoulos]

@mrbaseman Could it be that this is an old FortiGate appliance with obsolete ciphers that have been disabled by default in recent Linux distributions such as Ubuntu 20.04? Is it possible to re-enable these ciphers programatically from openfortivpn?

See for example:
microsoft/msphpsql#1023 (comment)
https://stackoverflow.com/questions/53058362/openssl-v1-1-1-ssl-choose-client-version-unsupported-protocol

[mrbaseman]

Well, you can choose ciphers with the --cipher-list option to override the default settings of the openssl which openfortivpn has been linked against. --min-tls and --insecure-ssl as you suggested are possible tweaks.
If the error appears only with the version from the deb package, it is perhaps linked against a different ssl library than in the snap?

[DimitriPapadopoulos]

Indeed the openfortivpn snap is built against core18 which has its own system libraries:

$ ls -l /snap/core18/current/lib/x86_64-linux-gnu/libcrypt.so.1
lrwxrwxrwx 1 root root 16 Apr 16  2018 /snap/core18/current/lib/x86_64-linux-gnu/libcrypt.so.1 -> libcrypt-2.27.so
$ 

So in effect it is as if the snap was running on an Ubuntu 18.04 machine although the host really is an Ubuntu 20.04 machine.

On the other hand the openfortivpn DEB package really runs on Ubuntu 20.04.

I'm afraid we will see this problem more often as more users migrate to Ubuntu 20.04 but still need to access older FortiGate appliances. Is there a way to detect older FortiGate appliances and programmatically downgrade the ciphers from openfortivpn, as most users won't know how to do that easily? Perhaps those FortiGate appliances that do not provide an XML config and respond with a 404 status code to /remote/fortisslvpn_xml requests? Or can that be done by changing the OpenSSL configuration only? Can we at least print an error message?
Alternatively we need to document that in the wiki - I don't know how to downgrade the ciphers myself.

[mrbaseman]

Maybe this is an unlucky combination of the oldest FortiOS that we have seen and the latest Ubuntu on the client side.
The FortiOS version is usually contained in the xml output. Without xml I presume it's an antique FortiOS release, perhaps 4.x.

[DimitriPapadopoulos]

Then perhaps it's worth printing a warning if the config is not available in XML format?

[mrbaseman]

yes, as long as parse_config() does not support the same features as parse_xml_config() we should at least display a warning. That's indeed worth adding a line of code...

[DimitriPapadopoulos]

I had a look at the VPN appliance and it's a FortiGate 100D as far as I can see:

And indeed the nmap command shows it supports only weak SSLv3 and TLS 1.0 ciphers:

$ nmap -Pn --script ssl-enum-ciphers -p 10443 xx.xx.xxx.xx
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-28 10:46 CEST
Nmap scan report for xx.xxx.xx.xx.rev.sfr.net (xx.xx.xxx.xx)
Host is up (0.033s latency).

PORT      STATE SERVICE
10443/tcp open  unknown
| ssl-enum-ciphers: 
|   SSLv3: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       CBC-mode cipher in SSLv3 (CVE-2014-3566)
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 1024) of lower strength than certificate key
|       Weak certificate signature: SHA1
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 1024) of lower strength than certificate key
|       Weak certificate signature: SHA1
|_  least strength: D

Nmap done: 1 IP address (1 host up) scanned in 4.32 seconds
$ 

@ethali Do you know by any chance the version of FortiOS? I don't have access to the Fortinet support site but have found on the internet that EOS of Fortigate 100D is 2022-09-13 and that it supports at least FortiOS 5.6:
https://www.reddit.com/r/fortinet/comments/6o95z0/fortigate_end_of_life_support/
Therefore it should be possible to install a decently recent and supported version of FortiOS.

In your case I see two possibilities:

1. Ask the administrator to upgrade the FortiGate appliance. It's probably outdated - and hence certainly vulnerable.
2. Modify the parameters of OpenSSL 1.1.1f on your Ubuntu 20.04 machine. Enable weak ciphers.

[mxmrlt]

Hi @DimitriPapadopoulos and @mrbaseman .

Thank you for taking time to watch this issue. As you say @DimitriPapadopoulos there will be problems for all people switching to 20.04 and connecting to old FortiOS.

Ask the administrator to upgrade the FortiGate appliance. It's probably outdated - and hence certainly vulnerable.

I asked the administrator what is the version of our FortiOS. here's the answer : v4.0,build0689,14215 (MR3 Patch 18)
So yes it's not a recent version.

Modify the parameters of OpenSSL 1.1.1f on your Ubuntu 20.04 machine. Enable weak ciphers.

Can you help me on this?

Well, you can choose ciphers with the --cipher-list option to override the default settings of the openssl which openfortivpn has been linked against. --min-tls and --insecure-ssl as you suggested are possible tweaks.

Maybe I could try this.

Fortunately and at least I can connect by VPN with the Snap version even if I have to set DNS servers manually...

[mrbaseman]

I believe all the D series models support up to FortiOS 6.0.x. I've started with 5.0 but I think the xml config was already there at that time, but maybe it was 5.2...

[DimitriPapadopoulos]

I asked the administrator what is the version of our FortiOS. here's the answer : v4.0,build0689,14215 (MR3 Patch 18)
So yes it's not a recent version.

It's completely outdated, unmaintained and dangerously vulnerable as far as I can tell 😃 I have deleted one of your comments, the long one that gives away too much about your FortiGate appliance - I was afraid it could lead to an easy and successful attack against your organisation...

[mxmrlt]

I asked the administrator what is the version of our FortiOS. here's the answer : v4.0,build0689,14215 (MR3 Patch 18)
So yes it's not a recent version.

It's completely outdated, unmaintained and dangerously vulnerable as far as I can tell smiley I have deleted one of your comments, the long one that gives away too much about your FortiGate appliance - I was afraid it could lead to an easy and successful attack against your organisation...

Yes thank you you did right.

[DimitriPapadopoulos]

I have added PR #676 to emit a warning when the FortiGate appliance is unable to provide an XML configuration.

[DimitriPapadopoulos]

Depending on the Linux distribution, you may even need to build and install your own version of OpenSSL. Not sure about Ubuntu 20.04, but I have found this discussion about TLS 1.0/1.1 support on a Debian mailing list:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875423

Perhaps we could call SSL_CTX_set_min_proto_version() / SSL_set_min_proto_version() in openfortivpn, it could work in cases where TLS1.0 is not entirely disabled in OpenSSL. But then I'm not certain any of the maintainers wants to spend time supporting outdated and dangerous VPN appliances 😃 On the other hand we may accept a patch provided by some else...

You may have to change a few things here, I really don't know:

openfortivpn/src/tunnel.c

Lines 972 to 1005 in 1baae9e

	} else {
	#if OPENSSL_VERSION_NUMBER >= 0x10100000L
	if (tunnel->config->min_tls <= 0)
	tunnel->config->min_tls = TLS1_VERSION;
	#endif
	if (!tunnel->config->cipher_list && tunnel->config->seclevel_1) {
	const char *cipher_list = "DEFAULT@SECLEVEL=1";
	tunnel->config->cipher_list = strdup(cipher_list);
	}
	}
	if (tunnel->config->cipher_list) {
	log_debug("Setting cipher list to: %s\n", tunnel->config->cipher_list);
	if (!SSL_set_cipher_list(tunnel->ssl_handle,
	tunnel->config->cipher_list)) {
	log_error("SSL_set_cipher_list failed: %s\n",
	ERR_error_string(ERR_peek_last_error(), NULL));
	return 1;
	}
	}
	#if OPENSSL_VERSION_NUMBER >= 0x10100000L
	if (tunnel->config->min_tls > 0) {
	log_debug("Setting min proto version to: 0x%x\n",
	tunnel->config->min_tls);
	if (!SSL_set_min_proto_version(tunnel->ssl_handle,
	tunnel->config->min_tls)) {
	log_error("SSL_set_min_proto_version failed: %s\n",
	ERR_error_string(ERR_peek_last_error(), NULL));
	return 1;
	}
	}
	#endif

[mxmrlt]

OK so the administrator gave an access to another FortiOS which is version 6.x. Now it works great under Ubuntu 20.04.

So this issue remains true to those who depend on an old FortiOS...
At least this thread permitted to highlight the problem.

Thank you all for your reactivity and kindness.

@DimitriPapadopoulos I let you close this issue (or not) if you think that is relevent (or not) ;-)

[mrbaseman]

even accepting a patch I would be careful if the aim is to work together with outdated openssl versions

[DimitriPapadopoulos]

@mrbaseman Yes,you're right about it. See also #677.

@ethali Those who depend on an old FortiOS are doomed anyway - it shouldn't be long before their system is taken over 😄

[DimitriPapadopoulos]

@ethali Forgot to ask, don't any of these options help?
--insecure-ssl
--min-tls=1.0
--seclevel-1

[mxmrlt]

@ethali Forgot to ask, don't any of these options help?
--insecure-ssl
--min-tls=1.0
--seclevel-1

@DimitriPapadopoulos It works great with
--seclevel-1
only indeed.

Thank you.