Why the GlobalProtect Linux Client Fails on Newer Ubuntu

The reasonable assumption is that the .deb from your GlobalProtect portal is broken, or that the vendor shipped a bad build. It usually is not. The vendor's Linux UI still links against Qt5 WebKit, and the newer Ubuntu releases no longer ship it, so the package is asking for a library that your distribution removed on purpose. That is a packaging mismatch, not a corrupted download, and the difference decides whether you spend the afternoon forcing packages or ten minutes choosing a different client.

The deb is not broken

A dependency the distribution no longer carries is a normal outcome of a library being retired. Qt5 WebKit was dropped from later Ubuntu archives and from Debian, and the reason was security maintenance rather than a lack of demand. When that happens, every package that still links against it stops being installable, no matter how well it was built.

Two failures get reported as the same bug and are not. On a release without the library, the installer stops with an unsatisfied dependency. On a release where the client installs and then fails at login, you are looking at a TLS or SAML handshake problem inside the embedded browser component instead. The first is packaging; the second is runtime, and neither is repaired by copying old libraries into a modern desktop.

Confirm the dependency instead of forcing it

Install the package explicitly so the tooling names the unresolved dependency instead of giving you a summary. Then ask whether your release has any candidate at all, because "not available here" and "temporarily missing from this mirror" lead to completely different decisions:

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

If apt-cache policy reports no candidate, stop trying to install it and start choosing an alternative. The interesting part is not the missing package name; it is the fact that the vendor's dependency graph has not moved with the distributions your users run.

What forcing old packages does to the desktop

The workaround that circulates is to pull the library from an older release. On a current Ubuntu that resolves into a Qt5 minor-version conflict: the older packages drag libqt5core5t64 backwards, and then installed KDE and PyQt packages begin demanding an ABI version that the downgraded library no longer provides. The result is a partial upgrade that breaks unrelated applications, which is a much worse afternoon than the one you started with.

That outcome is expected rather than unlucky. Qt's minor-version ABI expectations are strict, and a distribution ships one coherent set. Mixing in one library from another release is not a targeted fix; it is a second, less controlled upgrade.

The same advice applies to the runtime variant of the failure. Lowering the system-wide OpenSSL security level to make an old client's handshake succeed changes every TLS connection on the machine to repair one application, including the package manager you will need when something else breaks.

openconnect speaks the protocol

OpenConnect implements GlobalProtect's protocol directly, and the protocol notes describe both the invocation and the split between the two server interfaces. The portal distributes settings and the gateway list; the gateway terminates the tunnel:

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

If the portal omits the gateway you need, --usergroup=gateway or a URL ending in /gateway skips the portal step. When several gateways are offered, --authgroup=NAME chooses among them. Authentication is a username and password, optionally with a client certificate, and SAML gateways work in practice through network-manager-openconnect rather than a hand-typed command line.

A gateway with a strict posture policy may also require a HIP report before it hands out a tunnel. OpenConnect can generate and submit one, but if the gateway demands an inventory it cannot produce, no flag changes that policy; that is a server-side decision.

Verify the tunnel, and know what openconnect will not fix

Check what the tunnel actually applied rather than trusting the success message. The gateway sends routing and configuration as XML and the client applies it, so a missing route is a configuration or selection problem rather than a client bug:

ip -4 addr show
ip route
resolvectl status

MTU deserves its own look. The GlobalProtect configuration always reports an MTU of zero, so the client estimates one from encapsulation overhead. Large transfers that stall while small requests succeed are the classic symptom, and the remedy is an explicit MTU on the connection rather than turning off path discovery.

IPv6 is separate again. PAN added it in GlobalProtect 4.0, and OpenConnect's support is described as experimental from version 9.0, so do not assume the address family behaves like IPv4 just because the tunnel came up. And if the gateway enforces a posture check the open-source client cannot satisfy, run the vendor client on a supported LTS release, in a virtual machine if your workstation has moved on. That keeps the desktop intact and puts the legacy dependency inside a boundary you can rebuild.