# snx-rs: an open source client for Check Point VPN tunnels > snx-rs is an unofficial Check Point VPN client written in Rust, supporting IKEv1 and IKEv2 plus the legacy SSL tunnel, several login types including MFA and HSM tokens, and a GUI frontend with a tray icon. It is AGPL-3.0 licensed and ships as signed APT and DNF packages, a Homebrew formula and a Docker image. **ancwrd1/snx-rs** — Open Source Client For Check Point VPN Tunnels - Repository: https://github.com/ancwrd1/snx-rs - Stars: 528 · Forks: 51 - Language: Rust - License: AGPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/ancwrd1-snx-rs ## What the project is, and what unofficial means snx-rs contains the source code for an unofficial client for Check Point VPN, written in Rust. Currently supported platforms are Linux, Windows and macOS. The word unofficial is the first thing to weigh, and it is not a disclaimer about code quality. It means the client is not produced by Check Point, it is not covered by their support contract, and a change to the gateway's protocol behaviour on their side can break it without notice. For a home user connecting to a personal gateway that is a reasonable trade. For an enterprise deployment where the VPN is a business-critical path with a procurement process attached, it is a different conversation. The licence is the GNU Affero General Public License version 3, and the workspace manifest carries it as license = "AGPL-3.0". AGPL on a network client means that if you modify it and run it as a service for others, you owe them the modified source. For a client that people run on their own machines, the practical effect is that a fork that is distributed or offered to others has to make its modified source available, which is a deliberate choice by the author. The author is listed in the manifest as Dmitry Pankratov, and the repository has a CHANGELOG.md, an AGENTS.md and a CLAUDE.md at the root, alongside the crates, apps, package and docs directories. ## The protocol and login surface The Key Features list is where the real scope sits. On the protocol side there is IPsec with both IKEv1 and IKEv2, and legacy SSL tunnel support, which is the older transport some Check Point deployments still use for remote access. The login types are the part that determines whether the client will work with your gateway at all. The list covers multiple login types with MFA: identity provider, username and password, user and machine certificate, HSM token, and DynamicID. Those are five different authentication paths, and a gateway usually enforces one of them. A user whose gateway does single sign-on through an identity provider needs that path; a user whose organisation issues machine certificates needs that path; an HSM token path is for a hardware-held key. The feature existing does not mean your organisation's configuration is supported by it, so this is the first thing to check. Around that, the client offers client certificate enrollment and renewal, so it can obtain a certificate from the gateway rather than needing one provisioned by hand. OS keychain integration stores credentials in the platform's credential store rather than in a config file. Split DNS is offered for better privacy, meaning lookups for internal names resolve through the tunnel while others do not, and advanced routing configuration is a separate feature. Multiple connection profiles let one client hold several gateway configurations. The last feature is the one with a dedicated document. Persistent IPsec session for fast reconnect after network drops or suspend and resume is described in the repository as covered by the ike-persist document, and it is the kind of thing that matters on a laptop that sleeps. ## Native kernel IPsec on Linux Two implementation choices on Linux are worth separating, because they are frequently confused. The first is the native kernel IPsec support listed among the key features. On Linux, IPsec can be implemented in user space or handed to the kernel's own XFRM implementation. Doing the latter means the kernel handles the packet processing and the cipher work, with the client configuring the Security Associations and the policies. The practical benefits are that the encrypted traffic does not have to be routed through a userspace tunnel device, and that things like routing and firewalling behave the way the operating system's own network stack expects. The second is the Docker image, and the Dockerfile says plainly what that requires. The documented run command includes --net=host and the NET_ADMIN and NET_RAW capabilities, with a note that these are required for VPN tunnel establishment. That is the same constraint the native path implies: setting up routes and manipulating raw packets are privileged operations, and a container has to be granted them explicitly. For a container deployment this is the operational detail to plan for. Host networking plus two capabilities plus a config volume mounted at /home/snxuser/.config/snx-rs is not a lightweight arrangement, and the example in the Dockerfile mounts exactly that path for the config. The build side is a static musl binary, built with the snxcore/vendored-openssl and snxcore/vendored-sqlite features and the lto profile, using Rust 1.92 to satisfy dependency requirements. Vendoring OpenSSL and SQLite means the binary does not depend on the host's libraries, which is what makes the static build possible. ## The workspace layout and the shipped binaries The Cargo.toml declares a workspace with resolver 2 and five members: crates/snxcore, crates/i18n, apps/snxctl, apps/snx-rs and apps/snx-rs-gui. The split tells you the architecture. snxcore is the protocol implementation, i18n is the translation layer, snxctl is the command line client, snx-rs is presumably the library or headless binary, and snx-rs-gui is the graphical frontend. The GUI is not incidental, since a tray icon frontend is listed as a key feature and the package repository says only the default, non-webkit builds are served from the repositories while the -webkit variant remains available as a direct download from the releases page. That distinction is a packaging decision rather than a functional one, but it means the two builds are distributed differently and a user looking in the APT repository will not find the webkit variant. Two workspace lints are set that tell you about the code's standards. unsafe_code = "deny" forbids unsafe Rust outright, and unexpected_cfgs is allowed, which is a common accommodation for build scripts that set their own cfg flags. The release profile sets panic = "abort", and there is a separate lto profile with strip, lto and codegen-units = 1 for the smallest possible binary. The manifest is publish = false, which makes sense: the deliverable is a set of binaries and packages, not a library on crates.io, and the packages directory handles the Debian and RPM packaging. ## Packaging, and the Docker image in full Signed APT and DNF repositories with the latest release builds are published at ancwrd1.github.io/snx-rs, and the page lists the installation commands for Debian and Ubuntu and for Fedora, RHEL and openSUSE. A Homebrew package is also available, supporting both Linux and macOS, and the installation document links to it. That is a complete distribution story for the major desktop platforms, which is unusual for an unofficial client and is the main reason to consider this project over building from source. The Dockerfile carries its own instructions in comments. The build is docker build -t snx-rs ., and for Arch there is a build argument, docker build -t snx-rs --build-arg BASE=archlinux ., so the runtime base is configurable between alpine, which is the default, and archlinux. The build stage of the image is a static musl build: ```dockerfile FROM rust:1.92-slim AS builder ENV DEBIAN_FRONTEND=noninteractive WORKDIR /usr/src/snx-rs COPY . . ``` and with a config volume it mounts $PWD/config at /home/snxuser/.config/snx-rs. The note in the file repeats the constraint: --net=host and the NET_ADMIN and NET_RAW capabilities are required for VPN tunnel establishment. The build stage is rust:1.92-slim with build-essential, musl-tools, perl, pkg-config and the x86_64-unknown-linux-musl target added. The comments explain each: musl-tools for the musl-gcc cross compiler, perl for the openssl-sys Configure script, make and gcc for compiling C code, and pkg-config for finding libraries. OpenSSL and SQLite are vendored rather than linked from the system, which is what keeps the runtime image small. ## Where snx-rs is the wrong choice Three limits are structural. The first is that it is tied to one vendor's protocol. This client speaks Check Point's IPsec and legacy SSL tunnel configurations. If your organisation standardises on a different vendor, there is nothing here to reuse, and the alternative is a general purpose IPsec client with a configuration file, which is more widely understood and vendor-neutral but will not necessarily support the gateway's extensions. The second is the operational risk of an unsupported client in an enterprise setting. The gateway may require a specific IKE version, a specific rekey behaviour, a specific certificate profile or a specific identity provider handshake, and none of that is under the client's author's control. When something breaks, the debugging path goes through an unofficial project with a single maintainer rather than a vendor with a support contract. There is also a security consideration specific to a VPN client: it handles credentials and private keys for network access, so the trust question is sharper than for a typical open source tool, and AGPL at least means forks publish their changes. The third is that the feature list promises more than a single user's needs, and the parts you do not use still have to build and work. The HSM token and machine certificate paths, the enrollment flow and the split DNS are all there, but each adds surface area, and the Docker path adds privileged capabilities to the equation. The alternative is the vendor's own client, and the difference in approach is straightforward. The official client is what the gateway is tested against, it is supported, and it is what your security team has approved. snx-rs is a reimplementation in a different language with a community around it, which buys you an open client and a package you can inspect, at the cost of the guarantees you get from the vendor. For a personal connection the trade is often worth it; for a corporate policy the vendor client is usually the only acceptable answer. ## Conclusion snx-rs suits a Linux, Windows or macOS user who needs Check Point VPN and is not satisfied with the vendor's own client, since it covers the same tunnel protocols and login methods and is packaged for the major distributions. It is the wrong tool if you need a supported commercial product with a vendor behind it, and it is the wrong tool if your gateway is not a Check Point one, since the protocol coverage here is specific to that vendor. Verify first which of the login types your gateway enforces, since the MFA, HSM and certificate paths are separate features, and note that the newest release is v6.5.4 from 2026-10-19 with the last push on 2026-10-20. ## FAQ ### What is snx-rs and what does it do? It is an unofficial client for Check Point VPN written in Rust, supporting Linux, Windows and macOS. It handles IPsec with IKEv1 and IKEv2 as well as the legacy SSL tunnel, with multiple login types and a GUI frontend with a tray icon. ### Which login types does snx-rs support? Multiple login types with MFA: identity provider, username and password, user and machine certificate, HSM token, and DynamicID. Client certificate enrollment and renewal is also supported, so a certificate can be obtained from the gateway rather than provisioned by hand. ### How do I install snx-rs? Signed APT and DNF repositories with the latest release builds are published at ancwrd1.github.io/snx-rs, with installation commands listed for Debian and Ubuntu and for Fedora, RHEL and openSUSE. A Homebrew package supporting Linux and macOS is also available, and a Docker image can be built with docker build -t snx-rs . ### What does running the snx-rs Docker image require? The documented run command includes --net=host and the NET_ADMIN and NET_RAW capabilities, and the Dockerfile notes that these are required for VPN tunnel establishment. A config volume can be mounted at /home/snxuser/.config/snx-rs. ### What licence is snx-rs released under? The GNU Affero General Public License version 3, with license = "AGPL-3.0" in the workspace manifest and the AGPL badge in the README. The repository root carries the COPYING file. ### What is the persistent IPsec session feature in snx-rs? It keeps the IPsec session alive so that the client reconnects quickly after a network drop or a suspend and resume of the machine. The README links a dedicated document for it, docs/persistent-ipsec-session.md. ## Sources - [ancwrd1/snx-rs on GitHub](https://github.com/ancwrd1/snx-rs) - [Issues](https://github.com/ancwrd1/snx-rs/issues) - [License: AGPL-3.0](https://github.com/ancwrd1/snx-rs/blob/main/LICENSE) - [README](https://github.com/ancwrd1/snx-rs/blob/main/README.md) - [Releases](https://github.com/ancwrd1/snx-rs/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ancwrd1-snx-rs