[confighandler:EROR] cvt_util_vpn:71 Failed to allocate memory for fortitray IPC

I have the same problem. Where can I find the older version for downloading?

Hi, I've had the same problem and came up with the workaround below. Also contains details that may be helpful if you're debugging any kind of issue you're having with FortiClient.

Problem:

If we make an log export via the FortiClient VPN program, we see this in 'confighandler.log' (in the log ZIP file):

20240326 14:30:44.400 TZ=+0100 [confighandler:EROR] cvt_util_vpn:71 Failed to allocate memory for fortitray IPC

20240326 14:30:44.500 TZ=+0100 [confighandler:EROR] cvt_util_vpn:71 Failed to allocate memory for fortitray IPC

Symptoms:

- The FortiClient VPN program is unable to establish a VPN connection.

- The FortiClient VPN program is NOT showing a tray icon (or notification icon).

- The FortiClient VPN program is unable to show a 'certificate warning' (MAY or MAY NOT be applicable in your case).

- The 'forticlient' Linux service may have problems, like failing to open files or permission errors. Check with: systemctl status forticlient

Workaround:

Disabling AppArmor may help, although it will significantly reduce your system's security.

$ systemctl disable apparmor

$ reboot

Now, even though 'aa-enabled' will tell you that AppArmor is still enabled, you should see that 'sudo aa-status' shows that there aren't any apparmor profiles loaded.

It's a workaround, not an optimal solution. An optimal solution would require a proper AppArmor profile for the FortiClient VPN program and all its related binaries.

Problem #2:

You might see this error (see below) in your 'sslvpn.log' file, in the exported forti VPN client log ZIP file.

If you see this error while you were also experiencing the above (the '[confighandler:EROR] cvt_util_vpn:71 Failed to allocate memory for fortitray IPC' error), then you MAY or MAY NOT also observe that the FortiClient is unable to show you a certificate warning dialog (so you can't click Yes to continue), even though the 'sslvpn.log' file clearly indicates that the VPN client wants to show you a certificate confirmation dialog (but again, it fails to do so).

The error:

20240326 14:30:44.458 TZ=+0100 [sslvpn:DEBG] main:1402 Message to UI: You are connecting to an untrusted server, which could put your confidential information at risk. Would you like to connect to this server?

Hostname: vpn.mydomain.org

Reason: X509 verify certificate failed

Workaround #2:

The workaround shown earlier might help in this case too. For me, that workaround (disabling AppArmor and rebooting) made it possible for the FortiClient VPN program to show me a certificate warning dialog (which it wanted to show before, but it failed to show it). So I could finally click Yes to continue. The SSL certificate was actually valid (it could be seen in the browser by visiting the same VPN endpoint), so why FortiClient VPN shows it as invalid is a problem for another time.

Remarks:

To increase the chances that the FortiClient VPN program works on Linux, it may help to install the 'gnome-keyring' and 'gnome-keyring-pam' packages. The 'seahorse' (GNOME keyring GUI) package may be useful for investigative purposes, but it's not necessary.

In the Seahorse (GNOME keyring GUI) program you may see a FortiClientLinuxVPN secret. This entry seems to be temporarily set to a different value while connecting to the VPN. On a successful connection, the secret value is (in JSON format) set to {}

It seems safe to delete the value if you're investigating issues, and should re-appear the next time you make a VPN connection (even if the connection fails, the value should re-appear).

To communicate with the 'gnome-keyring', the FortiClient uses the org.freedesktop.Secrets DBUS API.

In the situation explained above, the issue was related to AppArmor. On machines with SELinux (which is similar to AppArmor) however, the above might NOT be a problem (meaning: the client creates a tray icon just fine and works as intended). I've tested the VPN client on Fedora 37 with the SELinux mode set to Enforcing.

In the workaround explained above, it appears that rebooting is necessary after disabling AppArmor. It's NOT enough to simply do 'aa-teardown' and 'systemctl restart forticlient'. Speculation: perhaps FortiClient leaves a bit of a mess in some runtime component such as gnome-keyring-daemon or dbus, thus requiring a reboot?

On openSUSE, if you install the FortiClient VPN package using 'zypper install ./forticlient_xx.rpm', it may complain about a libXext dependency. Usually you can ignore this problem, because openSUSE has named the package after its version number, such as libXext6. Usually that's the same version that other Linux distributions are using, so you don't have to do anything except ignore the problem. Also, openSUSE seems to be detected as Fedora by FortiClient.

Furthermore, it appears the FortiClient VPN program uses dbus and NetworkManager.

This snippet shows the forticlient service having trouble if AppArmor profiles are active (that is, while not having any proper AppArmor profiles for FortiClient):

$ systemctl status forticlient

● forticlient.service - Forticlient Scheduler

Loaded: loaded (/usr/lib/systemd/system/forticlient.service; enabled; preset: disabled)

Active: active (running) since Tue 2024-03-26 20:24:12 CET; 3min 24s ago

Main PID: 3775 (fctsched)

Tasks: 69 (limit: 3517)

CPU: 312ms

CGroup: /system.slice/forticlient.service

├─3775 /opt/forticlient/fctsched

├─3779 /opt/forticlient/confighandler

└─3932 /opt/forticlient/firewall

Mar 26 20:24:12 localhost.localdomain systemd[1]: Started Forticlient Scheduler.

Mar 26 20:24:12 localhost.localdomain fctsched[3775]: fopen() failed to open UID file [2]

Mar 26 20:24:12 localhost.localdomain fctsched[3775]: Failed to set machine ID file permissions [2]

Mar 26 20:24:12 localhost.localdomain slog[3775]: FortiClient Scheduler start ...