Check Point VPN on Linux: SNX is not a download you install

You go looking for the Check Point Linux client, and there is no download page with an installer on it. That absence is not a packaging gap. Check Point's Linux remote-access client is SSL Network Extender, SNX, and the gateway hands it to you after you authenticate in a browser. Once that lands, the rest of the confusion makes sense, including why almost every post about it is years old.

The myth: there is a client you download and install

The expectation comes from every other vendor. OpenVPN, WireGuard and most commercial clients publish a package or a repository, and installing one is a local decision you make alone. Check Point does not work that way for Linux. There is no standalone installer in the official downloads for current gateway versions, so searching for one turns up old forum threads and third-party mirrors.

Those mirrors are worse than useless, because the build has to match the gateway that serves it.

What SNX actually is, and where it comes from

SNX is a command-line client whose binary is snx, and it is installed over a session you start in the browser against the gateway. Historically a Java applet downloaded and installed it after you agreed to the prompt. The mechanism has changed over the years, the source has not. The gateway serves the build that matches itself, which is why client and gateway versions track each other, and why a client copied from an old package works only while the gateway still talks to it.

This also means the gateway has to be ready before any client work matters. Mobile Access Software Blade must be licensed and configured, because without it there is no portal to install from. No amount of client-side effort produces a session against a gateway that does not offer one.

Point the client at the gateway with your user, and read what it reports:

snx -s vpn.example.com -u your.name

Distribution support is the constraint, not the installer

The vendor's supported distribution list for SNX is short and old. In the published article it stops around Ubuntu 17.04, alongside a few openSUSE, Fedora and RHEL releases from the same era, and it still lists Ubuntu 12.10. That tells you how the list ages, not what your machine needs. A current distribution is simply not on it.

Expect library mismatches before you expect a working tunnel. The usual three are missing 32-bit libraries on a 64-bit system, an OpenSSL version the binary was never linked against, and a kernel module the client tries to build. Read the missing symbols instead of guessing at packages:

ldd $(command -v snx) | grep "not found"

Then check the support article for the gateway release you actually connect to. A blog's list is not a compatibility statement, and a newer distribution does not imply a newer client.

The X11 detail that makes headless work

SNX needs X11 libraries but not a running X server. That distinction is the whole difference between a client that works over SSH on a headless host and one that appears to hang with no output. Install the library package your distribution provides rather than a bundle copied from another release, and run the client from the session that needs the tunnel.

After it connects, read the interface and the routes before you trust either:

ip -brief addr show
ip route show

SNX creates a tunnel interface and installs the routes the portal defines. Those routes are the gateway's decision rather than yours, so a missing prefix is a gateway-side profile problem and not a client bug. Check DNS at the same time, because split-tunnel profiles often push a resolver you did not expect.

When SNX is the wrong answer entirely

Check Point gateways can also terminate IPsec and L2TP client-to-site connections, and those work with strongSwan, Libreswan or NetworkManager's L2TP plugin. That is a gateway configuration, not a client trick. If the gateway publishes only the Mobile Access portal, an IPsec client has nothing to negotiate with, and the log shows a timeout instead of an authentication failure. Ask which remote-access blades are enabled before you install anything else.

Every constraint here lives on the gateway side: the blade, the licence, the client build and the route profile. The CLI has worked for years. What breaks is the assumption that Linux support means a package you own and control.