rkueny / snx_install.sh
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
| 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/ |
sudo apt-get install libgtk2.0-0:i386 for ubuntu 16.04
I had to install theses packages also apt-get install libstdc++5:i386 libpam0g:i386 libx11-6:i386
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?
@flagod It’s a compressed tar archive located at the end of the script. In the line 17 extracts the file. it’s very common on proprietary software for Linux.
You can extract the snx binary:
$ tail -n +78 snx_install.sh > snx.n $ file snx.n snx.n: bzip2 compressed data, block size = 900k $ tar tf snx.n snx snx_uninstall.sh $ tar xf snx.n $ ls snx snx_install.sh snx.n snx_uninstall.sh $ file snx 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 failed to open file: /home/user/.snxrc Valid attributes are: - server SNX server to connet to - sslport The SNX SSL port (if not default) - username the user name - certificate certificate file to use - calist directory containing CA files - reauth enable automatic reauthentication. Valid values < yes, no >- debug enable debug output. Valid values < yes, 1-5 >- cipher encryption algorithm to use. Valid values < RC4 / 3DES >- proxy_name proxy hostname - proxy_port proxy port - proxy_user username for proxy authentication Thanks for the reply @nachohc ! is there any open source client that can be used as an alternative to snx?
If anyone is getting SNX: Authentication failed errors you might want to ensure you have installed snx build 800007075 . See https://unix.stackexchange.com/questions/450229/getting-checkpoint-vpn-ssl-network-extender-working-in-the-command-line
I know it’s been a long time, but do you have a newer snx version?
I have been using 800007075 but the checkpoint server was updated to use TLS 1.1 and now it doesn’t work.
I tried 800008061 too but no success.
They are advising us to use Windows. Help me =\
In the same situation than @erzads . please an update tu use snx client with updated server to use TLS1.1 and upper. Please help
Well I am on gentoo system, where C14 support is default, so being on GCC 6/7/8, therefore missing the libstdc++.so.5 library on my system, doesn’t work.
Thx a lot, hopefully its against on later libstdc++ version
Can anyone verify the md5sum of this script? I got
4372e9936e2dfb1d1ebcef3ed4dd7787 snx_install.sh Can anyone verify the md5sum of this script? I got
4372e9936e2dfb1d1ebcef3ed4dd7787 snx_install.sh @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,
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. Checkpoint vpn client linux
Если у вас не работает один из способов авторизации, сконвертируйте свой аккаунт по ссылке
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
После нескольких лет экспериментов мне таки удалось их соединить. Вообще-то Checkpoint использует IPSec, но, как водится, с некоторыми расширениями, делающими его несовместимыми с другими реализациями.
Родной клиент под линукс у Checkpoint’а когда-то был, но последняя версия была под RedHat 5 (не путать с RHEL5!). RH5 — это примерно 1997-98 год. С тех пор Checkpoint на линукс забил, а желающим рекомендует использовать SSL Network Extender, работающий через Java-плагин в браузере. Точнее, в моём случае не работающий, поскольку гейт по HTTPS вообще не отвечает.
Но добрые люди из компании Shrew Soft написали универсальный клиент, который умеет разговаривать на многих диалектах IPSec, включая CheckPoint’овский. Готового пакета под линукс у них самих нет, но из исходников собралось влёт. В некоторых дистрибутивах, типа убунты, говорят, есть уже готовое.
Остались сущие мелочи: настроить. В родной инструкции сказано, что клиенту нужен сертификат, который предлагается экспортировать из сервера. Но у меня нет доступа к серверу. Виндовый клиент этот сертификат скачивает при первом соединении с сервером и сохраняет у себя (способ небезопасный, но уж какой есть). Вот только сохраняет он его таким хитровывернутым способом…
Итак,
1) в Program Files\CheckPoint\SecuRemote\database\ находим файлик userc.C, в котором лежит конфигурация клиента. Файлик, к счастью, текстовый. Находим в нём параметр :cert, представляющий собой длинную строку из шестнадцатиричных цифр. И сохраняем эту строку в другой файлик, скажем, cert.hex
2) Конвертируем в бинарный вид: xxd -p -r cert.hex > cert.bin
3) Переставляем байты в обратном порядке… cat cert.bin | perl -0777e ‘print scalar reverse <>‘ > cert.der
4) Полученный файл представляет собой серверный сертификат в формате DER. Конвертируем в PEM: openssl x509 -inform DER -in cert.der -outform PEM -out cert.pem
Это Страшное Колдунство найдено тут.
Так, с сертификатом разобрались. Переходим к настройке параметров соединения..
Запускаем qikea, тыкаем в кнопочку Add. В полученном диалоге вбиваем следующие настройки:
General:
указываем IP-адрес гейта, порт 500.
Auto configuration: ike config pullю
Local Host Address method: Use a virtual adapter and assigned address и Obtain automatically.
MTU оставляем 1380.
Client:
NAT traversal: disable. Несмотря на это, оно успешно работает из-за NAT’а. Вероятно, эта настройка относится к собственно IPSec’овому NAT-T, а здесь он инкапсулируется в UDP, и NAT проходит на этом уровне. И в инструкции всё равно написано, что Shrew не поддерживает CheckPoint’овский NAT-T.
IKE fragmentation: enable, Max packet size: 540.
Остальные три галки (Enable Dead Peer Detection, Enable ISAKMP Failure Notifications, Enable Client Login Banner) оставляем как есть, то есть, включёнными.
Name resolution: оставляем по умолчанию:
Enable DNS, Obtain automatically. DNS suffix тоже Obtain automatically.
Учтите, что это приведёт к добавлению записей в /etc/resolv.conf при поднятии туннеля, если это нежелательно, можно выключить.
Authentication:
Authentication method: Hybrid RSA+XAuth.
Local Identity: User FQDN, UFQDN string оставляем пустой. В инструкции написано, что надо использовать FQDN, но у меня оно с такой настройкой не работает, только с UFQDN.
Remote Identity: Identification Type: any. В инструкции написано, что можно ещё IP address, я не пробовал.
Credentials: Server Certificate Authority File: вот тут надо указать файл с сертификатом, выковырянный на первом этапе. Сам файл больше уже не понадобится, он тут импортируется и целиком сохраняется в конфиге.
Phase1:
Exchange type: main. Agressive не работает.
DH Exchnage: group 2. Остальные варианты, включая auto, у меня не работают.
Cipher algorithm: AES, Key length: 256 bit. Auto не работает.
Hash algorithm: sha1. Auto не работает.
Key Life Time Limit: оставляем как есть: 86400 sec, data limit: 0 (в смысле, отключено).
Не забыть поставить галку Enable Check Point Compatible Vendor ID, без неё точно не заработает.
Phase2: всё про умолчанию:
Transfer algorithm: auto
HMAC Algorithm: auto
PFS Exchange: disabled
Compression algotithm: disabled
Key life time limit: 3600 sec, data limit: 0.
Policy:
Policy generation level: auto
Maintain persistent Security Associations: у меня выключено, в принципе, можно и включить, если кому надо.
Obtain Topology Automatically or Tunnel All: у меня выключено в связи с идиотской политикой, выдаваемой сервером. Он выдаёт маршрут в VPN для внешнего IP-адреса гейта. Причём в Windows этот идиотизм как-то работает, но в линуксе однозначно не будет. Поэтому все нужные маршруты далее вбить вручную. Тем более, что в инструкции написано, что автоматическое получение маршрутов из CheckPoint’а всё равно не работает.
Вот, собственно, и всё. Сохраняем, запускаем, вводим логин и пароль, и надеемся, что заработает..
Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.