-
-
Save rkueny/301f7ead21ed2a0ee8bbe2d755bed90b to your computer and use it in GitHub Desktop.
| mkdir temp && cd temp | |
| # for linux 'amd64' architecture install those packages: | |
| sudo apt-get install libx11-6:i386 libpam0g:i386 libstdc++5:i386 lib32z1 lib32ncurses5 lib32bz2-1.0 | |
| wget https://vpnportal.aktifbank.com.tr/SNX/INSTALL/snx_install.sh | |
| sudo ./snx_install.sh | |
| cd .. && rm -rf temp/ |
It works also for me. thanks!
I used 800007075 until the checkpoint server was updated to use TLS 1.1 . After that, until today, I used the following solution/workaround
Looks like older versions of SNX are not able to work with TLS 1.1. I am playing now with 800010003 from Checkpoint's site (link given by @yurayko, thanks), but no success. From "connection aborted" I have shifted to "authentication failed". 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:
[ 4011 -141392832]@debi[5 Aug 17:19:28] ===snx_CCC_browser::send_auth_message===
[ 4011 -141392832]@debi[5 Aug 17:19:28] sending message
[ 4011 -141392832]@debi[5 Aug 17:19:28] talkssl::send_data: Entering for 281 bytes
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_connbuf_realloc: reallocating 0 from 0 to 1305
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_mux_in: 6: rc=1, next: 80f2060 with 3, req: 512r, 281w
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_mux_out: 6: sent 0 of 281 bytes == 281 bytes to send
[ 4011 -141392832]@debi[5 Aug 17:19:28] ckpSSL_do_write: write 281 bytes
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_mux_out: 6: managed to send 281 of 281 bytes
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_mux_out: 6: call: 80f2060 with 3
[ 4011 -141392832]@debi[5 Aug 17:19:28] talkssl::client_handler: after sending packet
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_mux_out: 6: rc=1, next: 80f2060 with 3, req: 512r, 0w
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_mux_in: 6: got 0 of 512 bytes == 512 bytes required
[ 4011 -141392832]@debi[5 Aug 17:19:28] ckpSSL_do_read: read 411 bytes
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_mux_in: 6: managed to read 411 of 512 bytes
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_mux_in: 6: call: 80f2060 with 3
[ 4011 -141392832]@debi[5 Aug 17:19:28] talkssl::client_handler: state: SSL_RECV - entering
[ 4011 -141392832]@debi[5 Aug 17:19:28] talkssl::client_handler: got 411 bytes, wanted 512 bytes
[ 4011 -141392832]@debi[5 Aug 17:19:28] fwasync_conn_reset_read: 6
[ 4011 -141392832]@debi[5 Aug 17:19:28] talkssl::client_handler: calling recv with dlen 411
[ 4011 -141392832]@debi[5 Aug 17:19:28] Receive started
[ 4011 -141392832]@debi[5 Aug 17:19:28] snx_browser::Receive: started
[ 4011 -141392832]@debi[5 Aug 17:19:28] snx_browser::Receive: got 411 bytes
[ 4011 -141392832]@debi[5 Aug 17:19:28] snx_CCC_browser::getMessageSize: header length is 279, content length found - 128
[ 4011 -141392832]@debi[5 Aug 17:19:28] snx_browser::Receive: message size should be = 411
[ 4011 -141392832]@debi[5 Aug 17:19:28] snx_browser::Receive: complete message received
[ 4011 -141392832]@debi[5 Aug 17:19:28] snx_browser::Established: CCC_CLIENT_BAD_FORMAT
[ 4011 -141392832]@debi[5 Aug 17:19:28] snx: quit.
Hi, why does the snx_install.sh script have 4000 lines of binary code at the end? Isn't it supposed to be a shell script?
that's why I didn't run the script
GREAT this post saved me! 😆
Thanks, this helped me too.
I use this docker image: https://hub.docker.com/r/kedu/snx-checkpoint-vpn
and update the script with build 800010003.
https://supportcenter.checkpoint.com/supportcenter/portal/user/anon/page/default.psml/media-type/html?action=portlets.DCFileAction&eventSubmit_doGetdcdetails=&fileid=22824
@qg0 binary is x86, but your system is x86-64. Add multiarch support and install required libraries
build 800010003 works for me
https://supportcenter.checkpoint.com/supportcenter/portal/user/anon/page/default.psml/media-type/html?action=portlets.DCFileAction&eventSubmit_doGetdcdetails=&fileid=22824
wooow terima kasih bro, worked like charm
Hi guys!
I have segfault ([1] 147836 segmentation fault (core dumped)) and can run it again only after restarting the OS (Ubuntu 21.10). I assume there is some file that prevents the snx to run again. How can I solve this issue?
Thanks in advance
May be tunsnx remains active after crash?
ip a ?
Also try to start snx with debug snx -g
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 04:d4:c4:f1:34:a7 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.14/24 brd 192.168.1.255 scope global dynamic noprefixroute enp5s0
valid_lft 3019sec preferred_lft 3019sec
inet6 fe80::48ae:3767:b432:aca4/64 scope link noprefixroute
valid_lft forever preferred_lft forever
6: tunsnx: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet 10.11.12.41 peer 10.11.12.40/32 scope global tunsnx
valid_lft forever preferred_lft forever
inet6 fe80::50f9:5441:a75c:70be/64 scope link stable-privacy
valid_lft forever preferred_lft forever
I hope, snx -d must make disconnect and remove tunsnx
snx never crash on my Debian 11.2
I do snx -d but it still crashes
I fix this error! And I create this tutorial!
cd /usr/bin/
sudo sh snx_uninstall.sh
wget http://www.pucrs.br/trabalheremoto/snx_install_linux30.sh -O snx_install.sh
sudo bash snx_install_linux30.sh
sudo ldd /usr/bin/snx
sudo dpkg --add-architecture i386
cat /var/lib/dpkg/arch
sudo apt update
sudo apt install libpam0g:i386 libx11-6:i386 libstdc++6:i386 libstdc++5:i386 libnss3-tools
chmod +x snx_install_linux30.sh
sudo ./snx_install_linux30.sh
snx -s 127.0.0.1 -u myuser
now build 800010003 doesn't work for me,
it shows Connection Aborted after typing the password
any suggestions guys
I used to work with SNX connecting directly to CheckPoint VPN servers.
Meanwhile, CheckPoint VPN/snx was updated for TLS 1.2 and now CheckPoint checks for the user agent. Afaik, neither the old standalone version of SNX in the command line, nor snxvpn work anymore. Nowadays, it has to be SNX+CShell agent+Java+an Internet browser.
SNX and CShell install have also their share of problems, and I wrote a script to get around them and install them in a chroot, supporting many Linux distributions.
See https://github.com/ruyrybeyro/chrootvpn and the new chosen answer for https://unix.stackexchange.com/questions/450131/vpn-ssl-network-extender-in-firefox
I used to work with SNX connecting directly to CheckPoint VPN servers.
Meanwhile, CheckPoint VPN/snx was updated for TLS 1.2 and now CheckPoint checks for the user agent. Afaik, neither the old standalone version of SNX in the command line, nor snxvpn work anymore. Nowadays, it has to be SNX+CShell agent+Java+an Internet browser.
SNX and CShell install have also their share of problems, and I wrote a script to get around them and install them in a chroot, supporting many Linux distributions.
See https://github.com/ruyrybeyro/chrootvpn and the new chosen answer for https://unix.stackexchange.com/questions/450131/vpn-ssl-network-extender-in-firefox
Thank you, your solution worked for me!
In the meanwhile my solution was slightly adapted to Debian 12 and more linux distros.
I am using:
Ubuntu 24.04
Check Point's Linux SNX build 800010003
I was getting "Segmentation fault (core dumped)" trying to connect to my job vpn, my other team members that also use linux (Mint) were connecting normally so obviously the problem was my OS. Doing some investigation and I found the /etc/resolv.conf with some crazy data, deleted the file, rebooted the OS so the file could be autogenerated again and SNX was able to connect normally.
There should be some way to autogenerate the /etc/resolv.conf without rebooting after deleting it, if the stub file exists, try:
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
then
sudo systemctl restart systemd-resolved && sudo systemctl restart NetworkManager
then try reconnecting to your vpn.
Everytime I disconnect from my job vpn (snx -d) it leaves some dirty data in resolv.conf that might break following attempts to reconnect, so if you have problems connecting check resolv.conf.
I am using: Ubuntu 24.04 Check Point's Linux SNX build 800010003
I was getting "Segmentation fault (core dumped)" trying to connect to my job vpn, my other team members that also use linux (Mint) were connecting normally so obviously the problem was my OS. Doing some investigation and I found the /etc/resolv.conf with some crazy data, deleted the file, rebooted the OS so the file could be autogenerated again and SNX was able to connect normally.
There should be some way to autogenerate the /etc/resolv.conf without rebooting after deleting it, if the stub file exists, try:
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.confthensudo systemctl restart systemd-resolved && sudo systemctl restart NetworkManagerthen try reconnecting to your vpn.Everytime I disconnect from my job vpn (snx -d) it leaves some dirty data in resolv.conf that might break following attempts to reconnect, so if you have problems connecting check resolv.conf.
I have this error every now and then. I was able to overcome this problem by restarting resolved as you mentioned:
sudo systemctl restart systemd-resolved
I fix this error! And I create this tutorial!
cd /usr/bin/ sudo sh snx_uninstall.sh
wget http://www.pucrs.br/trabalheremoto/snx_install_linux30.sh -O snx_install.sh
sudo bash snx_install_linux30.sh sudo ldd /usr/bin/snx sudo dpkg --add-architecture i386 cat /var/lib/dpkg/arch sudo apt update sudo apt install libpam0g:i386 libx11-6:i386 libstdc++6:i386 libstdc++5:i386 libnss3-tools
chmod +x snx_install_linux30.sh
sudo ./snx_install_linux30.sh
ty @al4xs - worked!
chrootvpn did not work for me, as the Checkpoint I'm connecting to is pretty old
@icedwater got
md5sum snx_install_800007075.sh
4372e9936e2dfb1d1ebcef3ed4dd7787 snx_install_800007075.sh
but likely because we got it from same source. Did u make it work?
Thanks,