An ARM build is not FortiClient support for your Raspberry Pi

Running a VPN client on a Raspberry Pi is not the same thing as FortiClient being supported on it. Three claims get merged in this conversation: the vendor qualifies a platform, someone builds a binary for the processor, and the gateway permits that client's protocol and enrollment. Finding one of the three tells you nothing about the other two. Work through them in this order and stop when one fails, because that is the one you have to solve.

Step one: read the release note row for your exact package

Support statements are version-bound, so start with the release notes for the package your organisation approves. For a concrete example, the FortiClient Standalone 7.4.7 table lists Ubuntu 22.04 and 24.04, Red Hat 9 and CentOS Stream 9 with GNOME. Its Linux processor requirement is phrased as Intel or equivalent.

Raspberry Pi OS is not one of those listed Linux environments. That is not a verdict about every FortiClient edition or a prediction about later releases; it is a statement about that row in that document. Read the matrix for the version you actually intend to deploy.

Do not carry processor notes from the Windows or macOS rows into the Linux row. Vendors document platforms per edition and per release, and a note that applies to one row is not evidence about another.

Step two: confirm what the Pi is running

Three commands settle the local facts before any download:

uname -m
cat /etc/os-release
dpkg --print-architecture

The first tells you the kernel architecture, the second the distribution and release, and the third the user-space architecture packages are built for. A 64-bit kernel with a 32-bit user space is possible, and it changes which package you need.

Then check what is actually available for that platform. Debian trixie's published package table includes arm64 and armhf builds of openfortivpn. That establishes architecture availability in that distribution. It does not establish that Fortinet qualifies FortiClient on a derivative, and it does not establish that your organisation's gateway accepts the client.

Use supported packages and current release documentation rather than a cached package from an old release or a failed-build report from a forum thread. If a graphical frontend exists, qualify it separately: a command-line build that works does not prove the editor, secret storage and supervision of a desktop wrapper are maintained.

Step three: check the gateway before blaming the client

Upstream describes openfortivpn as a PPP-and-TLS client that starts pppd. That is a specific implementation, and it needs the gateway to offer a compatible mode. A server brand name is not a protocol agreement.

Collect the gateway release and the enabled access method, the approved hostname and its trust material, and the identity workflow the service requires, including any second factor and device posture check. A managed deployment can require enrollment steps that a third-party client has no way to perform.

Try the connection with the account you were issued, not an administrator's, because enrollment and policy are usually attached to the user:

sudo openfortivpn vpn.example.com:443 -u <username>

Read the failure, not just the exit code. A certificate error, a PPP timeout and a policy rejection are three different problems, and only one of them is about ARM.

Step four: accept it on the device, inside the agreement

Accept the setup with a real private resource, DNS resolution through the tunnel, and a reconnect after a network drop. Then confirm a destination that should stay unreachable still fails, because reachability alone does not prove the policy is right.

Record four facts together: the OS release, the user-space architecture, the client package version, and the gateway mode. Without all four, the next person cannot tell whether the setup is supported or merely working.

If the employer requires a managed FortiClient environment that the Pi cannot meet, ask for an approved endpoint or an approved access host. Do not disable peer validation, imitate posture checks, or replace the organisation's gateway to accommodate one machine. The conclusion to write down is which supported combination is authorised, not that closed-source software can never target ARM.