Всем привет!

Может кто знает, подскажите, пожалуйста: есть ли возможность политику комплаянса мобайл аксеса применять только для определённых пользователей, а не вешать её на шлюз для абсолютно всех?
Либо только для определённых групп пользователей, либо наоборот - делать исключения.. есть такая возможность?

Утро доброе!
Пробовал ли кто-то NATить за кластером Check Point с включённым блейдом IPSec другой VPN шлюз?
Задача в том, чтобы часть туннелей в зависимости от источника  терминировалась на чекпоинте, а часть с помощью static NAT  пересылалась на другой VPN шлюз, находящийся в DMZ.
Что-то не получилось завести такую конфигурацию, т.к. чекпоинт дропает "чужие" NAT-T пакеты с ошибкой (fw ctl zdebug drop):
@;42019;[vs_0];[tid_0];[fw4_0];fw_log_drop_ex: Packet proto=17 31.ХХ.196.106:4500 -> 185.УУ.120.1:4500 dropped by vpn_ipsec_decrypt Reason: decryption failure: Could not get SAs from packet;

отключал Control connections в Global Properties, создавал кастомное правило с сервисами UDP 500 и 4500  без инспекции - не помогло

а вот это не подходит?

да что-то как-то не похоже

Я полагаю вам нужно обратиться к статье sk86582. Если правильно понял вы хотите часть сетей исключить из VPN

нет, задача совсем другая.
нужно, чтобы определённые пиры строили туннель с чекпоинтом, а все остальные - со вторым шлюзом, который NATится за чекпоинтом

Пользователь Bhagabhai Sapra был забанен по подозрению в спаме.

по идее у вас IPsec порты висят на внешнем интерфейсе и уже используются самим Check Point, поэтому и дропаются другие пакеты которые адресованы не ему. Мне кажется тут самые простые варианты это выделить еще 1 белый IP и повесить его на внешний интерфейс для внутреннего VPN шлюза. Или изменить стандартные порты для IPSec на внутреннем шлюзе и спокойно пробрасывать их на ЧП.

Заказчик хочет, чтобы всё висело на 1 адресе. С отдельным то понятно, что будет работать

ну значит надо менять стандартные порты для IPSec на внутреннем шлюзе и пирах которые строят с ним связь или если есть возможность сделать это для ЧП. Увы в рамках ЧП с задачей смены дефолтных портов не сталкивался. На сторонних шлюзах С-Терра такая задача была и вполне решалась.

ну хочется официальный ответ какой-то получить, что так работать не будет. чтобы убедить заказчика в необходимости изменить топологию. открыл тикет ещё в поддержке, но там надолго. пока инженер внимательно прочитает описание, пока то да сё, уйдёт много времени

ну тут тогда только через тикет думаю) по факту это частая практика, что порты заняты уже собственными сервисами. Тут даже не знаю как это можно более детально разжевать Заказчику. Порт занят IPSec блейдом ЧП.

можете ему вот официальный sk показать по используемым портам. https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk52421#IPsec%20VPN%20/%20SecuRemote%20/%20SecureClient

Заказчик хочет получить в будущем лишние проблемы из-за желания использовать нестандартные порты для экономии 1 белого адреса...

Дело не в экономии адресов.
Сейчас все VPN туннели терминируются на Cisco ASA. На ней же куча удалённых пользователей по L2TP.
ASA меняется на чекпоинт, а сама убирается в DMZ за чекпоинт.
Задача - сделать перенос так, чтобы этого никто не заметил. Ни удалённые пользователи, ни удалённые пиры.
Часть туннелей переносится на Check Point, часть пока остаётся на ASA. В частности - остаётся та куча удалённых пользователей по L2TP.
Поэтому нельзя менять ни адрес, ни порты. Хотелось решить эту задачу с помощью NAT.

А если попробовать прописать вообще все наты: и те, что, придут на ср, и те, что на асу? На асу - обычный нат, а для ср - просто переначивать на "внутренний" интерфейс ср (со всеми сопутствующими настройками туннелей), полностью отключить implied rules.

а что даст переначивание на "внутренний" интерфейс ср?

типа не будет слушать на внешнем адресе?

Для этого, по идее, надо указать какие интерфейсы использовать для построения туннелей (есть настройка в графическом интерфейсе, и несколько полей правятся через dbedit)