openfortigui puts a FortiGate VPN tunnel in the system tray, and the sudo rule is one line

A GUI over openfortivpn, packaged for desktops rather than servers

The scope is small and clear. openfortigui is a VPN-GUI to connect to FortiGate hardware, based on openfortivpn, and the project page is at hadler.me/linux/openfortigui/. The point of the project is not to replace the protocol implementation but to give it a desktop front end. The repository layout shows where the pieces live, with an `openfortigui/` directory holding the application, a `krunner_openfortigui/` directory holding the KDE integration, a `packaging/` directory for the distribution packages, a `tests/` directory, and a `CMakeLists.txt` at the root alongside a `LICENSE` and a `LICENSE.OpenSSL`. The presence of the OpenSSL licence file next to the GPL one reflects the embedded openfortivpn dependency, which is worth knowing about before you redistribute the binary. The project also publishes an official public apt repository at apt.iteas.at/, which is where the packaged builds come from.

SAML sign-in opens a browser and catches a redirect on localhost

The SAML path is the feature that distinguishes this client from a plain terminal VPN. For gateways that authenticate via SAML, such as Microsoft SSO and the like, you enable Login via browser (SAML SSO) in the VPN profile. On connect, openfortiGUI opens your web browser on the gateway's SAML login page, and after signing in the gateway redirects to a local listener on `127.0.0.1`, with the port configurable in the profile and a default of 8020, and the tunnel comes up automatically. The mechanism is a loopback redirect that the browser delivers back to the application, which is the standard shape for this pattern. The alternative path is still available, since a manually obtained `SVPNCOOKIE` can still be pasted into the profile's Cookie field, which is the route for a gateway where the browser flow is not available or where you already have a session cookie in hand.

The passwordless sudo rule is scoped to one command and one path

The privileged part is deliberately narrow, and the documentation treats any confusion here as a bug in the setup rather than in the application. The VPN process needs root for pppd and the routing table, so openfortiGUI starts it through `sudo`, and the packages install a rule for exactly that one command:

%sudo  ALL=NOPASSWD: /usr/bin/openfortigui --start-vpn *

If connecting fails with the message that sudo asked for a password, that rule does not apply to your account. Two things have to be true, and the documentation names both: `/etc/sudoers` must contain `@includedir /etc/sudoers.d`, and you must be a member of the group the rule names. The awkward case is highlighted explicitly. Domain and AD accounts usually are not in the local `sudo` group, and in that case the documentation says to name their group in the rule instead, rather than granting general sudo rights:

%domain\ users  ALL=NOPASSWD: /usr/bin/openfortigui --start-vpn *

That is the security property to take from this project. The wildcard is on the arguments of one binary, not on a general command, so a user in that group can start a VPN connection without a password and nothing else.

Passwords live in the keyring when you ask them to

By default openfortiGUI encrypts the profile passwords itself, with the AES key and IV stored in `~/.openfortigui/main.conf`. Enabling Use system password store from the File to Settings menu moves the key and the IV into the keyring of your desktop session instead, so they are no longer readable in the configuration file. The implementation detail is worth noting: the application talks to a Secret Service provider through qtkeychain, not to any specific implementation, so the package you install depends on your desktop. The documented mapping is short:

| Desktop | Package | |---|---| | GNOME, Xfce, Cinnamon, i3/sway, … | `gnome-keyring` (plus `seahorse` to manage it) | | KDE Plasma | `kwalletmanager` (KWallet is part of Plasma) |

The `libgnome-keyring*` packages named in older issues are obsolete and are not used, and if the keyring is missing or locked the application says so when the option is switched on and leaves the option off rather than falling back silently. One consequence is easy to miss. Switching the option changes where the key and the IV live, not the passwords themselves, so passwords stored under the previous key have to be entered once again afterwards.

The tray icon is a requirement, not a convenience, and Wayland takes two of them away

openfortiGUI lives in the system tray: closing the window hides it and leaves the tunnel up, and the tray icon brings it back. The documentation is blunt that a tray only exists if something provides one. KDE Plasma ships a StatusNotifierItem host, and Ubuntu's GNOME enables the AppIndicator extension by default. Plain GNOME, meaning Fedora Workstation and Debian with GNOME, and wlroots sessions without a tray applet have none, and then there is no icon. What the application does in that case is the interesting part: it keeps running with the tunnel up, says so once when you close the window, and ignores start minimized rather than starting invisibly. Starting it again brings the window back, because the second start hands the request to the instance that is already running. Two Wayland limits are named as not fixable from inside the application. The first is that openfortiGUI cannot raise or focus its own window, because a Wayland client needs an activation token from the compositor tied to an input event it received itself, and a click in the tray menu goes to the panel while the StatusNotifierItem protocol carries no token, so Show mainwindow maps the window but cannot pull it in front of whatever you were looking at, whereas on X11 it can. The second is that window positions are the compositor's business: the window is centred on startup under X11 and placed by the compositor under Wayland. There is a documented escape hatch for both.

XWayland is the switch for the two Wayland behaviours

If either of the Wayland limitations matters to you, the documentation gives a one-line remedy that runs the application on XWayland, where both behaviours work as they do on X11:

The application can be run on XWayland with the `QT_QPA_PLATFORM=xcb` environment variable set to `xcb` and the `openfortigui` binary as the command.

This is worth understanding as a design constraint rather than a workaround. Under Wayland, the two things a tray application most wants, drawing attention to itself and placing its window, are the two things the protocol does not let a client do for itself. The application responds by degrading rather than by failing, and it tells you what it is doing. For a desktop user on Plasma, nothing is lost. For a user on plain GNOME with the AppIndicator extension installed, the icon returns and the raise limitation remains. For a user on a wlroots compositor with no tray applet at all, the application is usable but invisible, which is a state that is easy to mistake for a crash and worth understanding before you install it.

The 0.9.11 Qt6 port moved distributions and broke the KDE plugin

The upgrade notes are specific about what changed, and they are the clearest statement of the project's current shape. 0.9.11 is the Qt6 port, and profiles, groups, the configuration and stored passwords carry over unchanged, so there is nothing to migrate by hand. Four things do change. You have to restart openfortiGUI once after the upgrade, because a 0.9.10 GUI that keeps running cannot start new connections, since it may still call `sudo -E` which the new sudoers rule no longer permits, and a newly started 0.9.11 binary will not find the old GUI's socket, though established tunnels keep running. The supported distributions change, with Qt6 packages existing for Ubuntu 24.04 and later and Debian bookworm and later, while Ubuntu 20.04 and 22.04 and Debian 10 and 11 stay on the 0.9.10 line and apt keeps them there automatically. The KRunner plugin needs KDE Frameworks 6, on Ubuntu 26.04 or Debian trixie or later, and the KF5 plugin is removed on upgrade because it cannot talk to 0.9.11. And the embedded openfortivpn is 1.24.1, which drops the OpenSSL ENGINE code path for keys via PKCS#11 engines.

Where a FortiGate GUI is the wrong choice

Two limits are visible in the documentation. The first is that the whole thing is a desktop application with a system tray, a system keyring integration and a KDE plugin, so it belongs on a workstation and not on a server, and it is not a headless daemon that a script can call to open a tunnel. The documentation's only mention of testing is against a real FortiGate VM running under KVM, with the requirements and the test suite described in `TESTS.md`, which tells you the project is verified against real gateway behaviour rather than a mock. The second is the privilege model. The application needs a passwordless sudo rule for one command, and it needs it to be present in a sudoers.d file, and on a domain-joined machine where the local sudo group does not include you, someone has to edit that file. A script that runs `openfortivpn` directly with a credential from a secret store has no equivalent of this problem. The alternative to weigh against is exactly that, a small wrapper around openfortivpn driven by a systemd unit or a script, with the credential injected by the system's secret management rather than stored in a desktop keyring. The difference in approach is where the trust boundary sits. openfortiGUI assumes a human at a desktop who has already been granted one specific privilege, and it gives that human a window into the tunnel state. A wrapper assumes an automated environment where the credential is provisioned programmatically and no interactive session exists at all. For a person at a desk, the GUI is the better tool. For a server or a script, it is the wrong shape.

Editorial conclusion

openfortigui is worth installing if you connect to FortiGate hardware from a Linux desktop and want a tray application with saved profiles, browser-based SAML sign-in and keyring storage rather than a shell command, since the whole point of the project is that the tunnel lifecycle lives in a GUI while the connection itself is handled by the embedded openfortivpn. It is a poor fit if your account authenticates through a domain that the local sudo group does not cover, because the passwordless rule has to name that group explicitly, and a poor fit on a plain GNOME or wlroots session where no tray host exists, since the application will run with the tunnel up but no icon to click. Before installing, read the sudo section and confirm that `/etc/sudoers` includes `@includedir /etc/sudoers.d`, and note that the last push to the repository was on 2026-08-25 with release v0.9.13 published the same day.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. theinvisible/openfortigui on GitHub