потому что dynamic per, fortigate находится за серым NAT. Когда dynamic per, то pre-shared key недоступен

таки завел туннель, почему то используя IKEv1 при попытки phase1 ошибка на сертификат была, при IKEv2 все норм поднимается

В принципе странный вопрос. Это ж сисуриту

Action  negotiate
Status  negotiate_error
Reason  invalid certificate

Вот не показывает, это уведомление об ошибке с ЧП пришло, или ФГ так реагирует. Ну, заработало с IKEv2 и хорошо

С фортигейта

Если б с чп, можно было б предположить, что Link-Selection надо поправить и/или IP в Alternative name в сертификат фортика пихнуть. Но если это ФГ ортачился - то не знаю, пожалуй

Можно было бы подебажить посерьезнее, но нужно как всегда завтра. Вообще ФГ уедет на объект и там будет нормальный белый ip и можно было заюзать pre-shared key, но хотелось rsa.

Стопудово лучше RSA

Понятно, что секьюрно.)))) Вопрос был в том, почему не psk.

Почему?)))

Ответ потому что секьюрно не принимается.

Потому что dynamic per :)

Но, помимо секьюрности, rsa работает со static per и dynamic per, а вот psk только static per

У меня 20 туннелей с удаленными объектами. Иногда объекты закрываются и открываются новые, в этом случае ранее настроеный fw уезжает на другой объект и если до этого был static per + psk, а на новом месте dynamic per, то fw нужно перенастраивать на rsa.

👍 понятно

Это отличный вопрос. Зачем нам вообще нужен RSA и все сложности с сертификатами, если можно поставить ключ вручную и не заморачиваться.
Не будем затрагивать тему с тем, что при аутентификации пиров с динамическим IP аутентификация PSK невозможна технологически (Предположим, что настроены несколько пиров - и разные PSK для них. При установке VPN с динамическим пиром пятый-шестой пакеты с хэшами этих PSK должны быть зашифрованы, и ключи шифрования и аутентификации первой фазы расчитываются на основе корневой переменной SKEYID по RFC2409, но SKEYID расчитывается с использованием PSK, который в свою очередь не может быть выбран, так как выбирается по IP пира, с которым устанавливается VPN).

IPSec VPN - это совокупность протоколов, и некоторые из них своей математической изощренностью совершенно поражают воображение - если не функция хэширования, то Диффи-Хеллман точно. Многолетние исследования и криптоанализ, лучшие умы человечества, математика, достаточная чтобы обмениваться критичной информацией через публичные каналы связи. Но всё это летит по заветам Гражданской Обороны, если ваш сисадмин поставил на обеих сторонах PSK "аааа": брутфорс никто не отменял. С аутентификацией по сертификатам такого произойти не может.

Если две компании устанавливают VPN по PSK, то так или иначе одна сторона придумывает PSK и должна передать его второй стороне - возникает вопрос, как это сделать защищенным путем. С сертификатами этого нет. Не затрагивая тонкостей исполнения, для получения сертификата от сертификационного центра достаточно прислать ему сгенерированный публичный ключ и имя компании (Cert request), чтобы получить подписанный сертификат. При этом секретные данные никто никому не передает.

Еще пример, почему сертификаты лучше - когда у вас сотни филиалов и VPN между ними (Meshed), придумывать сложные PSK для каждой пары (и хранить эти PSK, конечно) - "ну, замучаешься же! Поставлю-ка я аааа". С сертификатами этого не будет: если все пиры Check Point - вообще ничего для этого делать не надо: менеджмент сервер автоматически выдает всем подписанные сертификаты. А если не все, то достаточно для каждого сделать доверенным корпоративный центр сертификации, в ЧП это - единожды на менеджмент-сервере.

👍 понятно

В смысле?)

Единый 80.40 на песок встаёт. Там не поправили пока описание

engine 9.7 поддерживает локальную эмуляцию на 80.40