Hi,
The pure command line setup of the Checkpoint VPN client, with a special edition of SNX, has already stopped working a couple of years ago with the discontinuation of SSLv3 support by Checkpoint.
Also around that time, the Java agent stopped being an applet in the browser, and became a Java servlet running on the client.
These setups are typically problematic with the various versions of Checkpoint installation scripts, dependencies are not always easy to satisfy, require 32-bit libraries, and in some distributions/versions these dependencies no longer exist (officially).
The official setup is not supported in RHEL/Fedora/CentOS. Here is my script that isolates the client/agent/32-bit setup in a chroot, and has been tested with many distributions, including Rocky.
Feedback is welcome.
Regards,
I’m interested to know, does it actually need java, and a browser, and the certificate (in the browser)? I’m running an experimental version using command line only on Rocky 8.6. One problem I ran into, was that the snx version on the firewall was out-of-date, and I had to get someone with a login to get me a newer version. The difference was exactly as you said, the TLS protocol level. I wonder if it could be decompiled and re-compiled as x64?
TLDR You need 32-bit SNX+Java+the CShell agent, which I am doing in a Debian chroot, plus a browser, which is running in the “host” Linux 64-bit distribution.
The old applet Java was moved to the client side around 2020/1 by CheckPoint and the old “special” snx floating around that allowed command line only mode only supported SSLv3, and was never released such an snx supporting TLS according to the CheckPoint Knowledge Base.
Also, the original snxvpn reverse reengineering project was abandoned by the original author, although there is a new snxvpn-fix which is not working for me.
I doubt about even CheckPoint moving snx to x64, snx seems to be a heavily hacked openssl C source over many years, stuck in the i386 land. (my guess, good as any other). It would be interesting hacking/writing a wrapper for a new TLS-aware SNX with the routines it is missing to be standalone as the old 800007075 build.
Please see Fully connecting via terminal skipping the WebUI · Discussion #7 · ruyrybeyro/chrootvpn · GitHub and chrootvpn/README.md at main · ruyrybeyro/chrootvpn · GitHub for a couple more details.
The one I’m using right now (without java, without browser) is at this link.
‘SNX Installation Package for Linux OS client (sk90240)’
Maybe our gateway is allowing SSLv3 (I don’t know for sure).
Both your version SNX 800010003 and the one downloaded from our VPN SNX 800008304 are not able to sustain a connection without Java and browser at my end.
Though we are using double factor auth, per the debugging logs, they seem able to authenticate however lose connection some steps ahead when invoked from the command line.
snx -server vpnxxxx -username xxxxx -g
Check Point’s Linux SNX
build 800010003
Please enter your password:
SNX: Connection aborted.
OK, the big difference is the two factor authentication, which I imagine would need a browser to get some kind of access token using web requests.
The gateway I use right now, does not require MFA, and that might explain why I can connect using command line only.
It’s interesting that the version in the link I provided seems to be newer than what you have on your gateway? It’s also newer than what is on my gateway.
I see this in the logs
init: Construct for xxx.yyy.24.6:443. No proxy configured
ssl_link:: ssl_link_ssl_nego_init: using 3DES with CKPSSL_ACCEPT_TLS1_2
ckpSSLctx_New: prefs = 1e
ckpSSLctx_New: CKPSSL_ACCEPT_TLS1_2 is turned on + (CKPSSL_ACCEPT_TLSV1 | CKPSSL_ACCEPT_SSL3)
ckpSSLctx_New: choose SSLv23_method == the highest TLS version available -> should provide TLS 1.2
I don’t know if that means it’s actually using TLS 1.2, or just that it thinks it’s available.
If I am reading correctly, yours still provides SSLv3, mine does not.
Can you check, using version ‘800010003’
First make sure the ‘tun’ module is loaded.
sudo modprobe tun
then try to connect using command line and with debug enabled, which should create an elg file in homedir.
/path/to/snx -s remote.your.domain -u youruser -g
if you get “connection aborted”, check the elg file
Already checked two days ago with 800010003 no dice. modprobe not needed, tun is compiled in the kernel, not a module.
You can see it failing, but in the elg log, you only notice it timeouts waiting for something.
Will try it again tomorrow.
Do you mean on Rocky Linux 8.6?
My bad, it is compiled as a module.
snx runs the command “/sbin/modprobe tun” though
Also tried command snx with logging. It finished the TLS negotiation and authenticated successfully, but seems to die when the checkpoint side is checking the client User-Agent.
------
[ 45128 -141147008]@linux[12 Nov 9:36:21] ckpSSL_NegotiateStep: current state = SSLv2/v3 read server hello A
[ 45128 -141147008]@linux[12 Nov 9:36:21] ckpSSL_VerifyCallback: no params or params->key_holder
[ 45128 -141147008]@linux[12 Nov 9:36:21] ckpSSL_NegotiateStep: should retry.
[ 45128 -141147008]@linux[12 Nov 9:36:21] ckpSSL_NegotiateStep: current state = SSLv3 read finished A
[ 45128 -141147008]@linux[12 Nov 9:36:21] ckpSSL_NegotiateStep: conncected, used TLSv1/SSLv3 ,AES128-SHA (-1)
[ 45128 -141147008]@linux[12 Nov 9:36:21] ckpSSL_connected: peer authenticated
[ 45128 -141147008]@linux[12 Nov 9:36:21] ckpSSL_connected: current state: SSL negotiation finished successfully
------------
.....
.....
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self' wss: ....
Pragma: no-cache
Cache-Control: no-store
Location: xxxxxxxxx/Login/BrowserSupport
Vary: User-Agent
[ 45128 -141147008]@linux[12 Nov 9:36:26] exists_in_buf: entering, type is 2
[ 45128 -141147008]@linux[12 Nov 9:36:26] exists_in_buf: returning 0
[ 45128 -141147008]@linux[12 Nov 9:36:26] exists_in_buf: entering, type is 5
[ 45128 -141147008]@linux[12 Nov 9:36:26] exists_in_buf: returning 0
[ 45128 -141147008]@linux[12 Nov 9:36:26] fwasync_mux_in: 7: rc=1, next: 80ee750 with 3, req: 512r, 0w
[ 45128 -141147008]@linux[12 Nov 9:36:26] ckpSSL_InputPending 1 pending bytes
[ 45128 -141147008]@linux[12 Nov 9:36:26] ckpSSL_InputPending 1 pending bytes
[ 45128 -141147008]@linux[12 Nov 9:36:26] fwasync_mux_in: 7: got 0 of 512 bytes == 512 bytes required
[ 45128 -141147008]@linux[12 Nov 9:36:26] ckpSSL_do_read: read 66 bytes
[ 45128 -141147008]@linux[12 Nov 9:36:26] fwasync_mux_in: 7: managed to read 66 of 512 bytes
[ 45128 -141147008]@linux[12 Nov 9:36:26] fwasync_mux_in: 7: call: 80ee750 with 3
[ 45128 -141147008]@linux[12 Nov 9:36:26] talkssl::client_handler: state: SSL_RECV - entering
[ 45128 -141147008]@linux[12 Nov 9:36:26] talkssl::client_handler: got 66 bytes, wanted 512 bytes
[ 45128 -141147008]@linux[12 Nov 9:36:26] fwasync_conn_reset_read: 7
[ 45128 -141147008]@linux[12 Nov 9:36:26] talkssl::client_handler: calling recv with dlen 66
[ 45128 -141147008]@linux[12 Nov 9:36:26] snx_browser::Receive: got 66 bytes
[ 45128 -141147008]@linux[12 Nov 9:36:26] snx_browser::Receive: got data
Content-Length: 3
Content-Type: text/html; charset=UTF-8
[ 45128 -141147008]@linux[12 Nov 9:36:26] exists_in_buf: entering, type is 2
[ 45128 -141147008]@linux[12 Nov 9:36:26] exists_in_buf: returning 0
[ 45128 -141147008]@linux[12 Nov 9:36:26] exists_in_buf: entering, type is 5
[ 45128 -141147008]@linux[12 Nov 9:36:26] exists_in_buf: returning 0
[ 45128 -141147008]@linux[12 Nov 9:36:26] fwasync_mux_in: 7: rc=1, next: 80ee750 with 3, req: 512r, 0w
[ 45128 -141147008]@linux[12 Nov 9:36:28] fwasync_mux_in: 7: got 0 of 512 bytes == 512 bytes required
[ 45128 -141147008]@linux[12 Nov 9:36:28] fwasync_mux_in: 7: peer closed connection
[ 45128 -141147008]@linux[12 Nov 9:36:28] fwasync_end_conn: scheduling the end of connection 7
[ 45128 -141147008]@linux[12 Nov 9:36:28] fwasync_do_end_conn: closing connection 7 (conn=a118400)
[ 45128 -141147008]@linux[12 Nov 9:36:28] talkssl::end_handler: ending connection
[ 45128 -141147008]@linux[12 Nov 9:36:28] snx_browser::Failure: entering with code: 2
[ 45128 -141147008]@linux[12 Nov 9:36:28] got link down!- exit
[ 45128 -141147008]@linux[12 Nov 9:36:28] snx: quit.
[ 45128 -141147008]@linux[12 Nov 9:36:28] snx_browser::~snx_browser: called
[ 45128 -141147008]@linux[12 Nov 9:36:28] talkssl::~talkssl: delete link
[ 45128 -141147008]@linux[12 Nov 9:36:28] talkssl::~talkssl: end
[ 45128 -141147008]@linux[12 Nov 9:36:28] done