Inet6 fe80::48ae:3767:b432:aca4/64 scope link noprefixrouteĦ: tunsnx: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 snx_browser::Established: CCC_CLIENT_BAD_FORMATġ: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

snx_browser::Receive: complete message received snx_browser::Receive: message size should be = 411 snx_CCC_browser::getMessageSize: header length is 279, content length found - 128 talkssl::client_handler: calling recv with dlen 411 talkssl::client_handler: got 411 bytes, wanted 512 bytes talkssl::client_handler: state: SSL_RECV - entering fwasync_mux_in: 6: managed to read 411 of 512 bytes fwasync_mux_in: 6: got 0 of 512 bytes = 512 bytes required talkssl::client_handler: after sending packet fwasync_mux_out: 6: call: 80f2060 with 3 fwasync_mux_out: 6: managed to send 281 of 281 bytes fwasync_mux_out: 6: sent 0 of 281 bytes = 281 bytes to send fwasync_connbuf_realloc: reallocating 0 from 0 to 1305 talkssl::send_data: Entering for 281 bytes When looking into the debug log (-g option from command line) I see, that all is ok, but the communication on the end is not wrong, looks like a wrong format: =snx_CCC_browser::send_auth_message= From 'connection aborted' I have shifted to 'authentication failed'. I am playing now with 800010003 from Checkpoint's site (link given by thanks), but no success.

Looks like older versions of SNX are not able to work with TLS 1.1. proxy_user username for proxy authentication reauth enable automatic reauthentication. sslport The SNX SSL port (if not default) Snx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, stripped Snx snx_install.sh snx.n snx_uninstall.sh Snx.n: bzip2 compressed data, block size = 900k You can extract the snx binary: $ tail -n +78 snx_install.sh > snx.n it's very common on proprietary software for Linux. It's a compressed tar archive located at the end of the script.

Check point vpn client linux