На самом деле дока по IPSec у микротика довольно бестолковая - например того, что хэш SHA256 не работает ни с чем кроме другого микротика, там не отражено.
Подьем туннелей на IPSec - имеется в виду "чистный" IPSec, а не L2TP/IPSec - их обычно путают состоит из нескольких этапов.
1. Создание "предложения" на каждом микротике - это такой корявый перевод термина proposal. В proposal указываются методы шифрования, хэши и группы Диффи-Хеллмана, которые могу применяться при согласовании параметров. Крайне важно, чтобы оба микротика нашли хотя бы один общий алгоритм шифрования и хэш, и чтобы группы Диффи-Хеллмана совпадали! Здесь же указывается время жизни второй фазы, после чего будет повторный "быстрый" обмен ключами.
2. Создание политики на каждом микротике, которая определяет, что собственно говоря будет шифроваться и что с этим шифрованным контентом делать. Здесь указываются виртуальные маршрутизируемые подсетки, адреса реальных концов туннеля, метод шифрования, используемый proposal
3. Создание удаленного подключения (peer), которое задает многое множество параметров. Здесь указывается IP и порт удаленной стороны, метод аутентификации, метод первичного обмена ключами - базовый или агрессивный, необходимость NAT Travesal (если один из микротиков за натом), проверку proposal, алгоритмы хэша и шифрования, группы Диффи-Хеллмана, время жизни первой фазы, необходимость DPD. Если аутентификация по сертификатам - указывают имена сертификатов, которые должны быть к этому времени уже импортированы. Если аутентификация по ключам - указывают значение ключа.
Если устройство само не инициирует установление туннеля, ставится флаг пассивности, иначе сразу после создания Peer-а, микротик начинает к нему долбиться. Если что-то не так - включите логирование. В микротике используется racoon, поэтому лог там ракуновский, strongswan-а нет, поддержки IKEv2 нет.
