не строится тунель в облако

стоит такой же Linux, только StrongSwan.

С какой целью в одинаковых дистрибутивах использовать разные ipsec?

Если StrongSwan должен только принимать соединение, а инициатором выступать всегда сторона с OpenSwan, то ″auto = add″.

Смотрите, что ходит на уровне пакетов, ЕМНИП, udp порт 500, на стороне вашего офисного сервера, приходят ли туда пакеты от облака, уходят ли ответные пакеты.

Или есть какие-то нюансы в настройке между StrongSwan и OpenSwan? А может это руки у меня кривые?

Соберите тестовую схему без облака и NAT и узнаете :-) Пока вобще не понятно, поднимали ли вы когда-либо ipsec между двумя linux-серверами.

С какой целью в одинаковых дистрибутивах использовать разные ipsec?

Нет, дистрибутивы разные. Я имел ввиду, что тоже линукс, а не циска какая-то.

Если StrongSwan должен только принимать соединение, а инициатором выступать всегда сторона с OpenSwan, то ″auto = add″.

Та не важно, кто будет инициатором. Лишь бы работало.

Смотрите, что ходит на уровне пакетов, ЕМНИП, udp порт 500, на стороне вашего офисного сервера, приходят ли туда пакеты от облака, уходят ли ответные пакеты.

Спасибо за подсказку, надо было первым делом это сделать.

Соберите тестовую схему без облака и NAT и узнаете :-) Пока вобще не понятно, поднимали ли вы когда-либо ipsec между двумя linux-серверами.

Я бы не против. Но руководству всегда надо на вчера и никто тебе не выделит времени на какое-то там тестирование. ipsec поднимали, но все было гораздо проще: на обоих концах strongswan и никакого НАТа.

а почему не openvpn, раз речь идёт об обычных линуксах, а не о цысках?

потому что, с IPSec я знаком, а с OpenVPN нет

Вобщем, рассказываю, может кому будет полезен мой опыт.
Во-первых, я использовал аутентификацию PSK, а не по сертификату. По-умолчанию сервера использовали ID, которое равно IP-адресу. И у меня ID сервера в облаке не совпадало с ID, которое ждал сервер в офисе, так как север в облаке был за NAT-ом и IP-адреса отличались. Strongswan в офисе этого не понимал.
В связи с этим был выставлен параметр rightid в файле ipsec.conf.
Следующий нюанс, это то что из-за разных ID пришлось слегка изменить ipsec.secrets. Я прописал на офисном роутере пароль для обоих облачных адресов, и глобального и локального. Подозреваю, что достаточно локального.
Словом, вот куски конфигов на сервере в офисе для наглядности.
ipsec.conf

conn myconn
left=<mypublicip>
leftsubnet=172.16.0.0/24
right=<mycloudip>
rightid=10.240.82.13
rightsubnet=10.240.82.0/24
authby=secret
auto=start
pfs=no

ipsec.secrets

<mypublicip> <mycloudip> : PSK «supersecretketkey»
<mypublicip> 10.240.82.13 : PSK «supersecretketkey»

Еще используя этот роутер в облаке должны были ходить в офис через тунель другие облачные сервера. Я не знал, как оно получится, так как у этого убунту-роутера по факту только один сетевой интерфейс и получется какая-то фигня. Но тем не менее все заработало, оказалось достаточно прописать на серверах маршруты в офисную сеть через этот убунту-роутер и пакеты побежали.
mky должен тебя поблагодарить, ты уже второй раз меня наставляешь на путь истинный ;)

P.S. И обратите внимание на тот NAT-файрвол, который у вас в облаке выпускает сервера в сеть. Не забудьте его соответственным образом настроить.

На опеннете или ещё каком-то ресурсе со светленькой темой был материалец пару лет назад, о том что PSK и айпишники в ipsec — уязвимое в перехвату говно. Поздравляю с успешным применением своих знаний ipsec.