SNX on Linux: 32-Bit Libraries and a Resolver That Resets

SNX on Linux fails at the loader, the route table or the resolver, and each one looks like a login problem. Work the four symptoms in order.

Check Point's SSL Network Extender fails on Linux in four recognisable ways, and three of them get misread as a login problem. The binary will not start, or it starts and leaves no route, or it connects and name resolution dies, or the browser portal works while the command line does not. Work them in that order, because each one is the entry condition for the next.

Symptom one: the loader refuses before the login

The installer pulled from the firewall drops a 32-bit, setuid-root binary at /usr/bin/snx. On a 64-bit distribution it does not run until the i386 architecture is enabled and the libraries it links against exist.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

An empty not found list is the gate for everything after it. The exact package set moves between releases: one working report needed libstdc++5:i386, libx11-6:i386 and libpam0g:i386, another also needed libstdc++6:i386. Read ldd rather than copying a package list from a tutorial written for a different distribution.

If snx is not found at all, the installer never completed or installed somewhere outside your PATH. That is a different failure, and it is worth confirming before you add architectures to the system. Check with command -v snx and look in the directory the installer reported. Adding i386 packages to a machine where the binary is simply absent fixes nothing.

Symptom two: login succeeds and nothing routes

A successful login creates tunsnx and edits the routing table itself, so check what actually exists before you change anything else.

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

Use snx -d for teardown. Killing the process leaves the interface and its routes behind, and the next attempt then fails for a reason that has nothing to do with credentials. The first login also records a server signature under /etc/snx/, which is why an unattended script may need one interactive run before it can work at all. Delete that state only when you intend to re-approve the server.

Symptom three: names resolve until the tunnel comes up

This is the one that quietly breaks. snx writes pushed DNS servers straight into /etc/resolv.conf. Where that path is a symlink into /run/systemd/resolve/, the edit can be lost at the next resolver event, and after a disconnect the pushed entries can equally well stay behind.

Two arrangements work, and the choice should be deliberate rather than whatever the first search result suggested:

  • Take the file over: replace the symlink with a static file and install libnss-resolve plus its i386 variant, so name service still has a fallback when the file is rewritten underneath it.
  • Keep systemd-resolved as the owner and register the tunnel link: resolvectl dns tunsnx 10.0.0.10, then resolvectl domain tunsnx corp.example, and confirm with resolvectl status.

Record the pre-VPN nameservers before connecting. If you edit the file by hand, removing the pushed entries afterwards is part of the procedure, not optional cleanup, because a laptop that keeps corporate DNS after disconnect will fail to resolve anything else.

Symptom four: the portal works and the CLI does not

Recent firewall releases moved the middleware out of the browser into a local Java daemon, so the portal talks to a local agent on port 14186. That address needs a browser certificate exception and a running process.

ps ax | grep cshell
/usr/bin/cshell/launcher

The command line is a separate path: snx -s vpn.example.com -u user, with ~/.snxrc holding the server, user name and reauthentication preference. A working portal session says nothing about whether the CLI is installed correctly, and the bare client does not handle one-time codes.

The container shortcut that costs more than it saves

snx checks for the tun module, loads it when absent, creates a tunnel interface, rewrites routes and pushes traffic through it. Reproducing that inside a container means mounting /dev and /lib/modules and granting broad capabilities, which hands the container most of the host's network administration.

When a sandbox is genuinely required, a virtual machine is the cleaner boundary: the client gets a kernel it may modify, and the host keeps its route table. Choose that before you spend an afternoon on capabilities you will regret granting.

Nuŋlɔɖi siwo ku ɖe eŋu