CityCat4

не используя какой либо из vpn?

Никак. И очень советую почитать про то, что такое VPN.

различие...İpsec а в транспортном и туннельном режиме

Это в гугл.

Порядок создания опишу завтра - если кто-то другой не напишет раньше :)

Берем простейший случай - аутентификация по PSK (Pre-Shared Keys, то бишь простому текстовому паролю). Текст пароля "123456" (понятно, что если реализовывать такой вариант, пароль должен быть посерьезней)

Внешние интерфейсы, смотрящие в тырнет:
система А - 170.70.70.1
система Б - 180.80.80.1
(обязательно поменяйте их на свои!)

Внутренние интерфейсы, смотрящие в спариваемые локалки:
система А - 10.1.1.1
система Б - 10.2.2.1
маски у обеих сетей - /24 (255.255.255.0)

итак погнали.

RouterOS 6.45.7
значения по умолчанию не указываются
Система А (на системе Б будет все тоже, только перевернуто зеркально)

Шаг 0 - создаем предложение
Этот шаг необязательный

/ip ipsec proposal
add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=proposal1

Самое первое - создаем proposal. Это наше предложение другой стороне о том, какие мы поддерживаем шифры и какие методы подписи пакетов. Выбираем самое сильное шифрование AES256 со счетчиком Галуа, отдельная подпись пакета не потребуется. Здесь же мы задали время жизни туннеля до неполного переустановления - 1 час.
Этот шаг необязательный, он нужен только для усиления защиты туннеля. Без него будет набор из более простых шифров типа AES128 CBC с SHA1 в качестве алгоритма подписи пакета

Шаг 1 - создаем профиль соединения

/ip ipsec profile
add dpd-interval=disable-dpd enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=2h name=profile1 \
    nat-traversal=no proposal-check=strict

Отключаем DPD - от него только проблемы, устанавливаем более мощные чем по умолчанию алгоритмы шифрования и хэширования (default encrypt может быть и 3DES, default hash - SHA1), устанавливаем время жизни туннеля 2 часа (после - полная переустановка соединения со сбросом ключей шифрования), отключаем NAT Travesal, указываем обработку предложений strict (очень важный параметр! Если время жизни туннеля, запрошенное той стороной больше чем задано у нас - послать, если меньше или равно - принять)

Шаг 2 - создаем напарника (данные об удаленной системе)

/ip ipsec peer
add address=170.70.70.1/32 comment="Main VPN" name=RB2011 profile=profile1

Тут даже пояснять ничего не надо, все самоочевидно

Шаг 3 - создаем политику

/ip ipsec policy
add dst-address=10.2.2.0/24 peer=RB2011 proposal=proposal1 src-address=10.1.1.0/24 tunnel=yes

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

Шаг 4 - создаем идентификаторы (identity). Раньше в IPSec у микротика было меньше сущностей и обьяснение было проще...

/ip ipsec identity
add peer=RB2011 secret=123456

Естественно возникает вопрос - а как же микротик узнает, куда девать пакеты? А это записано у него в настройках - все пакеты с сети 10.1.1.0/24 на 10.2.2.0/24 зашифровать и отправить на 170.70.70.1, все пакеты же с 170.70.70.1 протокола ESP нужно расшифровать и обработать повторно.
Вообще для того, чтобы понять, как ходят пакеты в IPSec - есть отличная схема Packet Flow in Netfilter and General Networking

Схема есть? Если нет - надо построить и помедитировать над распределением адресов и тем фактом, что в сети может быть "лишний" dhcp.

Я правильно понимаю, что это у нас новая инкарнация чемпиона бредовых вопросов Freedom_Toster , он же Nickname_not_name? Тот же стиль, тот же "качественно нелепый" бред, как будто чел сидит, читает Олиферов и по ходу чтения выдает какие-то фееричные вещи, которые нарочно не придумаешь...

Если шифрование и защищенность не важна - то какой угодно, хоть pptp. Если важна - IPSec.
Два белых IP упростят настройку, но важно наличие одного, тогда соединение всегда устанавливает второй (который с серым IP). Если есть два, то пофиг кто устанавливает соединение.

Тут надо немного поработать головой... Маршрутизация, что в микротике, что в шване - она будет политиками делаться, от политик и нужно плясать, учитывая то, что политика воспринимается буквально.
Как я себе это представляю:
Пакет, например от 192.168.1.1 на 192.168.77.1 приходит на микротик А. Политика предписывает этот пакет зашифровать и упаковать в ESP, где IP src 10.22.10.1, IP dst 10.22.10.2. Микротик А должен знать, как доставить этот пакет, и он знает.
Пакет пришел на швана. Шван расшифровал его и видит пакет от 192.168.1.1 на 192.168.77.1. Он должен знать, что с ним делать :) иначе фиганет его на default route. То есть у швана должна быть политика, говорящая, что ему делать с пакетом от 192.168.1.1 на 192.168.77.1, а ее похоже нет. Тогда он поступит в соответствии с политикой.

Хоть десять провайдеров :) микротик позволяет.

Политики IPSec настроены? В них правильно указаны подсети, публичные адреса IP-шлюзов?
IKE и ESP не фильтруются?

Максимальная простота, если пофиг на шифрование - PPTP. Его все знают, все умеют.

У чистого IPSec нет клиентской и серверной частей. Микротик запросто подымает соединение сам :)

Написать политику таким образом, чтобы локальный трафик попадал в туннель.
Трафик в цепочке output проходит стандартный путь: mangle->nat->filter, потом попадает в цепочку postrouting, где проходит mangle->nat, после чего ведро проверяет по таблице политик безопасности IPSec (security policy table) - нужно ли этот пакет шифровать?
Если шифровать нужно, то пакет шифруется в соответствии с таблицей ассоциаций безопасности (security associations table) и зашифрованный пакет снова проходит весь указанный путь

Решения принимает тот, кто главный :)

Поэтому фильтровать, куда пускать юзеров с филиала нужно на центральном микротике. Не знаю, как это делается в L2TP, но в чистом IPSec пакеты проходят Filter два раза и фильтрую я их на втором проходе, когда они уже расшифрованные.

winbox

Но знание того, как работает iptables - все равно необходимо.

А с той стороны - не racoon ли? У меня такое было на FreeBSD - после окончания lifetime SA категорически отказывалась помирать и первая фаза не проходила.
Можно включить подробный лог и посмотреть, что происходит.
Я всегда ставлю strict.