IPsec на MikroTik — site-to-site туннель с IKEv2

IPsec (Internet Protocol Security) — набор протоколов для шифрования и аутентификации трафика на сетевом уровне. В отличие от связки L2TP/IPsec, где IPsec лишь оборачивает L2TP-туннель, чистый IPsec работает без промежуточного протокола — меньше overhead, выше производительность, проще отладка. В этом руководстве мы настроим site-to-site туннель между двумя офисами на MikroTik RouterOS 7.20+ с использованием IKEv2, разберём каждый компонент конфигурации, включим аппаратное ускорение и рассмотрим типичные ошибки.

Описание

Почему чистый IPsec, а не L2TP/IPsec

L2TP/IPsec удобен для подключения мобильных клиентов — Windows, macOS и iOS поддерживают его «из коробки». Но для соединения двух маршрутизаторов (site-to-site) L2TP добавляет ненужный уровень инкапсуляции:

Для site-to-site сценария чистый IPsec — правильный выбор: меньше точек отказа, выше пропускная способность, проще диагностика.

IKEv1 vs IKEv2

IKE (Internet Key Exchange) — протокол согласования параметров шифрования и обмена ключами. RouterOS поддерживает обе версии:

Рекомендация: используйте IKEv2 для всех новых конфигураций. IKEv1 оправдан только при подключении к оборудованию, не поддерживающему IKEv2 (старые Cisco ASA, Juniper ScreenOS).

Компоненты IPsec в RouterOS

Конфигурация IPsec в RouterOS 7 состоит из нескольких связанных сущностей:

code
Копировать
Profile (Phase 1)     — параметры IKE-согласования
    ↓
Proposal (Phase 2)    — параметры шифрования данных (ESP/AH)
    ↓
Peer                  — удалённая сторона (IP-адрес, профиль)
    ↓
Identity              — способ аутентификации (PSK, сертификат)
    ↓
Policy                — какой трафик шифровать (src/dst подсети)

Profile (Phase 1 / IKE SA) определяет:

• DH group — группа Диффи-Хеллмана для обмена ключами (modp2048, modp3072, ecp256)
• Encryption algorithm — шифрование IKE-сообщений (aes-256, aes-128)
• Hash algorithm — алгоритм хеширования (sha256, sha512)
• Lifetime — время жизни IKE SA (по умолчанию 1 день)

Proposal (Phase 2 / IPsec SA) определяет:

• Enc-algorithms — шифрование данных (aes-256-cbc, aes-256-gcm)
• Auth-algorithms — аутентификация данных (sha256, sha512; не нужно для GCM)
• PFS group — Perfect Forward Secrecy (рекомендуется modp2048 или ecp256)
• Lifetime — время жизни IPsec SA (по умолчанию 30 минут)

Peer — определяет удалённую сторону: IP-адрес или DNS-имя, используемый Profile, порт (500/4500).

Identity — привязывает способ аутентификации к Peer: pre-shared key (PSK), сертификат или EAP.

Policy — задаёт, какой трафик направлять в туннель: исходная подсеть (src-address), целевая подсеть (dst-address), протокол, действие (encrypt).

Выбор алгоритмов шифрования

Правильный выбор алгоритмов — баланс между безопасностью и производительностью. RouterOS 7.20 поддерживает следующие комбинации:

Шифрование (enc-algorithms):

GCM (Galois/Counter Mode) — предпочтительный режим. Он выполняет шифрование и аутентификацию за одну операцию (AEAD), что быстрее раздельных CBC + HMAC. Кроме того, GCM лучше параллелизуется на аппаратных ускорителях.

При использовании CBC обязательно указывайте auth-algorithms (sha256 или sha512). При GCM — auth-algorithms не нужен (встроенная аутентификация).

Группы Диффи-Хеллмана (DH group):

Эллиптические кривые (ecp256, ecp384) обеспечивают ту же безопасность при значительно меньшей длине ключа, что ускоряет согласование. Для новых конфигураций рекомендуется ecp256 или modp2048 как минимум. Группа modp1024 считается небезопасной и не должна использоваться.

Схема сети

В нашем примере мы соединяем два офиса:

• Офис A (HQ): WAN 203.0.113.10, LAN 192.168.10.0/24, роутер RB5009
• Офис B (Branch): WAN 198.51.100.20, LAN 192.168.20.0/24, роутер hAP ax3
• Протокол: IKEv2, PSK-аутентификация, AES-256-GCM

code
Копировать
  Офис A (HQ)                        Офис B (Branch)
┌─────────────┐                    ┌──────────────┐
│ 192.168.10.0/24 │─── IPsec ───│ 192.168.20.0/24 │
│ WAN: 203.0.113.10 │  tunnel   │ WAN: 198.51.100.20 │
└─────────────┘                    └──────────────┘

Настройка

Шаг 1. Profile (Phase 1)

Создаём одинаковый профиль на обоих роутерах. Используем современные алгоритмы:

[admin@MikroTik] >
Копировать
/ip/ipsec/profile/add \
  name=ike2-profile \
  hash-algorithm=sha256 \
  enc-algorithm=aes-256 \
  dh-group=modp2048 \
  lifetime=1d \
  proposal-check=obey \
  nat-traversal=yes \
  dpd-interval=30s \
  dpd-maximum-failures=5

Параметры:

• dh-group=modp2048 — 2048-битная группа Диффи-Хеллмана, баланс безопасности и скорости. Для максимальной безопасности используйте ecp256 (эллиптические кривые)
• nat-traversal=yes — включаем NAT-T на случай, если одна из сторон окажется за NAT
• dpd-interval=30s — Dead Peer Detection, проверка доступности удалённой стороны каждые 30 секунд
• dpd-maximum-failures=5 — после 5 неудачных DPD (2.5 минуты) туннель будет пересогласован
• proposal-check=obey — принимать параметры удалённой стороны, если они не слабее наших

Шаг 2. Proposal (Phase 2)

[admin@MikroTik] >
Копировать
/ip/ipsec/proposal/add \
  name=ike2-proposal \
  enc-algorithms=aes-256-gcm \
  lifetime=30m \
  pfs-group=modp2048

Параметры:

• enc-algorithms=aes-256-gcm — AES-256 в режиме GCM (Galois/Counter Mode). GCM одновременно шифрует и аутентифицирует данные, поэтому отдельный auth-algorithms не нужен. Если используете CBC — укажите auth-algorithms=sha256
• pfs-group=modp2048 — Perfect Forward Secrecy. При каждом пересогласовании Phase 2 генерируется новый ключ через DH. Компрометация одного ключа не раскрывает предыдущий трафик
• lifetime=30m — пересогласование каждые 30 минут. Для GCM рекомендуется не больше 1 часа

Шаг 3. Peer

На роутере Офиса A (HQ):

[admin@MikroTik] >
Копировать
/ip/ipsec/peer/add \
  name=peer-branch \
  address=198.51.100.20/32 \
  profile=ike2-profile \
  exchange-mode=ike2

На роутере Офиса B (Branch):

[admin@MikroTik] >
Копировать
/ip/ipsec/peer/add \
  name=peer-hq \
  address=203.0.113.10/32 \
  profile=ike2-profile \
  exchange-mode=ike2

Параметр exchange-mode=ike2 явно указывает использовать IKEv2. По умолчанию RouterOS использует IKEv1 main mode.

Шаг 4. Identity (аутентификация)

Используем pre-shared key. Ключ должен быть одинаковым на обеих сторонах. Сгенерируйте надёжный ключ длиной не менее 32 символов:

На роутере Офиса A (HQ):

[admin@MikroTik] >
Копировать
/ip/ipsec/identity/add \
  peer=peer-branch \
  auth-method=pre-shared-key \
  secret="Jx9#mK2$vL5nQ8@wR3pT7yB0hF6dA1cE"

На роутере Офиса B (Branch):

[admin@MikroTik] >
Копировать
/ip/ipsec/identity/add \
  peer=peer-hq \
  auth-method=pre-shared-key \
  secret="Jx9#mK2$vL5nQ8@wR3pT7yB0hF6dA1cE"

Внимание: в продакшене вместо PSK рекомендуется использовать сертификаты. PSK одинаковый на обеих сторонах — компрометация одного устройства раскрывает ключ для обоих.

Шаг 5. Policy (какой трафик шифровать)

Policy определяет, какие подсети будут доступны через туннель.

На роутере Офиса A (HQ):

[admin@MikroTik] >
Копировать
/ip/ipsec/policy/add \
  peer=peer-branch \
  src-address=192.168.10.0/24 \
  dst-address=192.168.20.0/24 \
  tunnel=yes \
  sa-src-address=203.0.113.10 \
  sa-dst-address=198.51.100.20 \
  proposal=ike2-proposal \
  action=encrypt \
  level=require

На роутере Офиса B (Branch):

[admin@MikroTik] >
Копировать
/ip/ipsec/policy/add \
  peer=peer-hq \
  src-address=192.168.20.0/24 \
  dst-address=192.168.10.0/24 \
  tunnel=yes \
  sa-src-address=198.51.100.20 \
  sa-dst-address=203.0.113.10 \
  proposal=ike2-proposal \
  action=encrypt \
  level=require

Обратите внимание: src-address и dst-address зеркально отражены на двух роутерах. sa-src-address и sa-dst-address — это WAN-адреса роутеров (внешние точки туннеля).

Шаг 6. Firewall и NAT bypass

IPsec-трафик между подсетями не должен попадать под masquerade (NAT). Без этого правила пакеты из LAN будут натиться на WAN-адрес прежде, чем попадут в IPsec-policy, и туннель не заработает.

На роутере Офиса A (HQ):

[admin@MikroTik] >
Копировать
# NAT bypass — трафик между офисами не натится
/ip/firewall/nat/add \
  chain=srcnat \
  src-address=192.168.10.0/24 \
  dst-address=192.168.20.0/24 \
  action=accept \
  comment="IPsec: no NAT to Branch" \
  place-before=0

На роутере Офиса B (Branch):

[admin@MikroTik] >
Копировать
/ip/firewall/nat/add \
  chain=srcnat \
  src-address=192.168.20.0/24 \
  dst-address=192.168.10.0/24 \
  action=accept \
  comment="IPsec: no NAT to HQ" \
  place-before=0

place-before=0 — размещаем правило перед masquerade, чтобы оно срабатывало первым.

Также нужно разрешить IPsec-трафик в input chain (если у вас строгий firewall):

[admin@MikroTik] >
Копировать
/ip/firewall/filter/add \
  chain=input \
  protocol=udp \
  dst-port=500,4500 \
  action=accept \
  comment="Allow IKE and NAT-T" \
  place-before=0

/ip/firewall/filter/add \
  chain=input \
  protocol=ipsec-esp \
  action=accept \
  comment="Allow IPsec ESP" \
  place-before=0

Для forward chain разрешите трафик между подсетями:

[admin@MikroTik] >
Копировать
/ip/firewall/filter/add \
  chain=forward \
  src-address=192.168.10.0/24 \
  dst-address=192.168.20.0/24 \
  ipsec-policy=in,ipsec \
  action=accept \
  comment="Allow IPsec forward from HQ to Branch"

/ip/firewall/filter/add \
  chain=forward \
  src-address=192.168.20.0/24 \
  dst-address=192.168.10.0/24 \
  ipsec-policy=in,ipsec \
  action=accept \
  comment="Allow IPsec forward from Branch to HQ"

NAT-T (NAT Traversal)

Если одна из сторон IPsec-туннеля находится за NAT (например, провайдер выдаёт серый IP), стандартный IPsec (ESP, IP protocol 50) работать не будет — NAT не умеет транслировать ESP-пакеты.

NAT-T решает проблему, оборачивая ESP-пакеты в UDP порт 4500:

code
Копировать
Без NAT-T:  IP → ESP (protocol 50)          — не проходит NAT
С NAT-T:    IP → UDP:4500 → ESP             — проходит NAT

В нашей конфигурации NAT-T уже включён в профиле (nat-traversal=yes). RouterOS автоматически определит наличие NAT и переключится на UDP 4500.

Если обе стороны имеют белый IP — NAT-T не активируется, трафик идёт через ESP (protocol 50), что эффективнее.

Проверить использование NAT-T:

[admin@MikroTik] >
Копировать
/ip/ipsec/active-peers/print detail

Поле natt-peer покажет yes, если NAT-T активен.

Аппаратное ускорение (Hardware Acceleration)

Некоторые модели MikroTik имеют аппаратные криптоускорители:

Проверить наличие аппаратного ускорения:

[admin@MikroTik] >
Копировать
/system/resource/print

В поле board-name указана модель. Также можно проверить загрузку CPU при активном туннеле — если CPU загружен на 100% при шифровании, ускорителя нет.

Для максимальной производительности используйте:

• aes-256-gcm вместо aes-256-cbc — GCM оптимизирован для аппаратного ускорения
• ecp256 вместо modp2048 для DH group — эллиптические кривые быстрее при том же уровне безопасности
• lifetime=1h для Phase 2 — реже пересогласование, но не больше 1 часа для GCM

Оптимизированная конфигурация для RB5009/CCR:

[admin@MikroTik] >
Копировать
/ip/ipsec/profile/set ike2-profile \
  dh-group=ecp256 \
  enc-algorithm=aes-256 \
  hash-algorithm=sha256

/ip/ipsec/proposal/set ike2-proposal \
  enc-algorithms=aes-256-gcm \
  pfs-group=ecp256 \
  lifetime=1h

Проверка

Статус подключения

После настройки обеих сторон туннель должен подняться автоматически при появлении трафика, соответствующего policy. Для принудительной инициализации — отправьте ping из одной подсети в другую:

[admin@MikroTik] >
Копировать
# С роутера Офиса A — пинг устройства в Офисе B
/ping 192.168.20.1 src-address=192.168.10.1 count=5

Проверка Phase 1 (IKE SA)

[admin@MikroTik] >
Копировать
/ip/ipsec/active-peers/print detail

Ожидаемый вывод:

code
Копировать
 0   peer=peer-branch state=established
     local-address=203.0.113.10 remote-address=198.51.100.20
     side=initiator uptime=2h15m30s
     ph2-total=1 natt-peer=no
     established=mar/15/2026 10:30:15

Ключевые поля:

• state=established — Phase 1 успешно согласована
• side=initiator или responder — кто инициировал подключение
• ph2-total=1 — количество активных Phase 2 SA
• natt-peer=no — NAT-T не используется (обе стороны с белым IP)

Проверка Phase 2 (IPsec SA)

[admin@MikroTik] >
Копировать
/ip/ipsec/installed-sa/print detail

Ожидаемый вывод:

code
Копировать
 0   peer=peer-branch direction=in
     src-address=198.51.100.20 dst-address=203.0.113.10
     auth-algorithm=none enc-algorithm=aes-256-gcm
     current-bytes=15234567 current-packets=10234
     add-lifetime=30m/25m12s replay-size=64
     state=mature hw-aead=yes

 1   peer=peer-branch direction=out
     src-address=203.0.113.10 dst-address=198.51.100.20
     auth-algorithm=none enc-algorithm=aes-256-gcm
     current-bytes=12345678 current-packets=8765
     add-lifetime=30m/25m12s replay-size=64
     state=mature hw-aead=yes

Ключевые поля:

• state=mature — SA активна и работает
• hw-aead=yes — используется аппаратное ускорение
• current-bytes / current-packets — счётчики трафика (должны расти при активном обмене)
• enc-algorithm=aes-256-gcm — подтверждение используемого шифрования
• Должно быть две SA — одна direction=in, вторая direction=out

Проверка policy

[admin@MikroTik] >
Копировать
/ip/ipsec/policy/print stats

Столбцы ph2-count и ph2-state покажут состояние. ph2-state=established означает, что policy активна и трафик шифруется.

Мониторинг трафика

[admin@MikroTik] >
Копировать
# Счётчики на policy
/ip/ipsec/policy/print stats

# Трафик через туннель в реальном времени
/tool/torch interface=ether1 src-address=192.168.10.0/24 dst-address=192.168.20.0/24

Логирование IPsec

Для детальной отладки включите логирование:

[admin@MikroTik] >
Копировать
/system/logging/add topics=ipsec action=memory

Просмотр логов:

[admin@MikroTik] >
Копировать
/log/print where topics~"ipsec"

После завершения отладки отключите — IPsec генерирует много сообщений:

[admin@MikroTik] >
Копировать
/system/logging/remove [find where topics~"ipsec"]

Добавление третьего офиса

Для подключения ещё одного офиса (например, 192.168.30.0/24 на WAN 192.0.2.50) повторите шаги 3–6 для каждой пары роутеров. Profile и Proposal можно переиспользовать:

На роутере Офиса A (HQ) — добавляем peer для Офиса C:

[admin@MikroTik] >
Копировать
/ip/ipsec/peer/add \
  name=peer-office-c \
  address=192.0.2.50/32 \
  profile=ike2-profile \
  exchange-mode=ike2

/ip/ipsec/identity/add \
  peer=peer-office-c \
  auth-method=pre-shared-key \
  secret="aB3@kL9#mN5$pQ7&rT1!vX4%yZ8wF2h"

/ip/ipsec/policy/add \
  peer=peer-office-c \
  src-address=192.168.10.0/24 \
  dst-address=192.168.30.0/24 \
  tunnel=yes \
  sa-src-address=203.0.113.10 \
  sa-dst-address=192.0.2.50 \
  proposal=ike2-proposal \
  action=encrypt \
  level=require

/ip/firewall/nat/add \
  chain=srcnat \
  src-address=192.168.10.0/24 \
  dst-address=192.168.30.0/24 \
  action=accept \
  comment="IPsec: no NAT to Office C" \
  place-before=0

Используйте разные PSK для каждой пары. Не копируйте один ключ на все туннели — компрометация одного ключа не должна затрагивать другие.

Аутентификация через сертификаты

Для продакшн-среды рекомендуется использовать сертификаты вместо PSK. Создаём CA и сертификаты на одном из роутеров и экспортируем на другой:

[admin@MikroTik] >
Копировать
# Создаём CA
/certificate/add name=ipsec-ca common-name="IPsec CA" \
  key-size=2048 days-valid=3650 key-usage=key-cert-sign,crl-sign
/certificate/sign ipsec-ca

# Сертификат для Офиса A
/certificate/add name=cert-hq common-name="HQ-Router" \
  key-size=2048 days-valid=1825 \
  key-usage=digital-signature,key-encipherment,tls-client
/certificate/sign cert-hq ca=ipsec-ca

# Сертификат для Офиса B
/certificate/add name=cert-branch common-name="Branch-Router" \
  key-size=2048 days-valid=1825 \
  key-usage=digital-signature,key-encipherment,tls-client
/certificate/sign cert-branch ca=ipsec-ca

Экспортируем сертификат и ключ для Офиса B:

[admin@MikroTik] >
Копировать
/certificate/export-certificate cert-branch export-passphrase="ExportPass123"
/certificate/export-certificate ipsec-ca

Файлы появятся в /file — перенесите их на роутер Офиса B через Winbox или SCP. На роутере Офиса B импортируем:

[admin@MikroTik] >
Копировать
/certificate/import file-name=ipsec-ca.crt
/certificate/import file-name=cert-branch.crt passphrase="ExportPass123"
/certificate/import file-name=cert-branch.key passphrase="ExportPass123"

Затем меняем Identity на обоих роутерах:

[admin@MikroTik] >
Копировать
# Офис A
/ip/ipsec/identity/set [find peer=peer-branch] \
  auth-method=digital-signature \
  certificate=cert-hq \
  remote-certificate=cert-branch

# Офис B
/ip/ipsec/identity/set [find peer=peer-hq] \
  auth-method=digital-signature \
  certificate=cert-branch \
  remote-certificate=cert-hq

Типичные ошибки

1. Phase 1 не поднимается — «no phase2 proposal chosen»

Самая частая ошибка — несовпадение параметров Profile или Proposal на двух сторонах. Проверьте что на обоих роутерах одинаковые:

[admin@MikroTik] >
Копировать
# Сравните вывод на обоих роутерах
/ip/ipsec/profile/print detail where name=ike2-profile
/ip/ipsec/proposal/print detail where name=ike2-proposal

Параметры, которые должны совпадать:

• Profile: hash-algorithm, enc-algorithm, dh-group
• Proposal: enc-algorithms, auth-algorithms, pfs-group

Частая ловушка: на одной стороне aes-256-gcm, на другой aes-256-cbc + sha256. Это разные конфигурации, Phase 2 не согласуется.

2. Туннель поднялся, но трафик не идёт

Проверьте NAT bypass. Если трафик между подсетями попадает под masquerade, исходный IP заменяется на WAN-адрес, и пакет не соответствует IPsec policy:

[admin@MikroTik] >
Копировать
# Проверьте порядок NAT-правил
/ip/firewall/nat/print

# Правило accept для IPsec-подсетей должно быть ПЕРЕД masquerade

Также проверьте, что policy не конфликтует с другими policy:

[admin@MikroTik] >
Копировать
/ip/ipsec/policy/print

Правило с src-address=0.0.0.0/0 dst-address=0.0.0.0/0 (default policy) может перехватывать трафик раньше вашего правила.

3. Туннель падает за NAT

Если одна из сторон за NAT, проверьте:

• nat-traversal=yes в Profile
• UDP порты 500 и 4500 проброшены на внешнем NAT-устройстве
• Нет двойного NAT (роутер за роутером)
• DPD настроен (dpd-interval=30s) — без DPD туннель за NAT может «зависать» при смене NAT-маппинга

[admin@MikroTik] >
Копировать
# Проверка NAT-T
/ip/ipsec/active-peers/print
# Если natt-peer=yes — NAT-T активен, значит NAT обнаружен

4. Ошибка «peer not found for 198.51.100.20»

Peer настроен с конкретным адресом, но удалённая сторона подключается с другого IP (динамический IP, NAT). Решение — используйте address=0.0.0.0/0 в peer и ограничьте доступ через Identity:

[admin@MikroTik] >
Копировать
/ip/ipsec/peer/set peer-branch address=0.0.0.0/0

Это снижает безопасность — любой IP сможет инициировать IKE-подключение. Используйте надёжный PSK или сертификаты.

5. Низкая скорость — CPU 100%

Если CPU загружен на 100% при передаче через IPsec — нет аппаратного ускорения. Варианты:

• Перейти на модель с криптоускорителем (RB5009, CCR2004, CCR2116)
• Понизить шифрование: aes-128-gcm вместо aes-256-gcm (быстрее на ~30%, безопасность всё ещё достаточна)
• Уменьшить DH group: ecp256 вместо modp4096
• Увеличить lifetime в Proposal чтобы реже пересогласовывать

[admin@MikroTik] >
Копировать
# Проверка загрузки CPU
/system/resource/print
# Посмотрите cpu-load в процентах

6. Policy conflict — трафик не попадает в туннель

Если есть несколько IPsec policy (например, для L2TP/IPsec и для site-to-site), порядок имеет значение. Более специфичная policy должна быть выше:

[admin@MikroTik] >
Копировать
# Переместите policy вверх
/ip/ipsec/policy/move [find where dst-address=192.168.20.0/24] 0

7. Проблемы с MTU / фрагментация

IPsec добавляет overhead к каждому пакету. Если MTU на WAN = 1500, а ESP-заголовок занимает 50–70 байт, полезная нагрузка уменьшается. Симптомы: ping работает, но HTTP/SSH зависают (большие пакеты не проходят).

Решение — настройте MSS clamping:

[admin@MikroTik] >
Копировать
/ip/firewall/mangle/add \
  chain=forward \
  protocol=tcp \
  tcp-flags=syn \
  ipsec-policy=in,ipsec \
  action=change-mss \
  new-mss=1360 \
  passthrough=yes \
  comment="IPsec: clamp MSS"

Это ограничит размер TCP-сегментов, проходящих через IPsec-туннель, предотвращая фрагментацию.

Profile (Phase 1)     — параметры IKE-согласования
    ↓
Proposal (Phase 2)    — параметры шифрования данных (ESP/AH)
    ↓
Peer                  — удалённая сторона (IP-адрес, профиль)
    ↓
Identity              — способ аутентификации (PSK, сертификат)
    ↓
Policy                — какой трафик шифровать (src/dst подсети)
Офис A (HQ)                        Офис B (Branch)
┌─────────────┐                    ┌──────────────┐
│ 192.168.10.0/24 │─── IPsec ───│ 192.168.20.0/24 │
│ WAN: 203.0.113.10 │  tunnel   │ WAN: 198.51.100.20 │
└─────────────┘                    └──────────────┘
/ip/ipsec/profile/add \
  name=ike2-profile \
  hash-algorithm=sha256 \
  enc-algorithm=aes-256 \
  dh-group=modp2048 \
  lifetime=1d \
  proposal-check=obey \
  nat-traversal=yes \
  dpd-interval=30s \
  dpd-maximum-failures=5
/ip/ipsec/proposal/add \
  name=ike2-proposal \
  enc-algorithms=aes-256-gcm \
  lifetime=30m \
  pfs-group=modp2048
/ip/ipsec/peer/add \
  name=peer-branch \
  address=198.51.100.20/32 \
  profile=ike2-profile \
  exchange-mode=ike2
/ip/ipsec/peer/add \
  name=peer-hq \
  address=203.0.113.10/32 \
  profile=ike2-profile \
  exchange-mode=ike2
/ip/ipsec/identity/add \
  peer=peer-branch \
  auth-method=pre-shared-key \
  secret="Jx9#mK2$vL5nQ8@wR3pT7yB0hF6dA1cE"
/ip/ipsec/identity/add \
  peer=peer-hq \
  auth-method=pre-shared-key \
  secret="Jx9#mK2$vL5nQ8@wR3pT7yB0hF6dA1cE"
/ip/ipsec/policy/add \
  peer=peer-branch \
  src-address=192.168.10.0/24 \
  dst-address=192.168.20.0/24 \
  tunnel=yes \
  sa-src-address=203.0.113.10 \
  sa-dst-address=198.51.100.20 \
  proposal=ike2-proposal \
  action=encrypt \
  level=require
/ip/ipsec/policy/add \
  peer=peer-hq \
  src-address=192.168.20.0/24 \
  dst-address=192.168.10.0/24 \
  tunnel=yes \
  sa-src-address=198.51.100.20 \
  sa-dst-address=203.0.113.10 \
  proposal=ike2-proposal \
  action=encrypt \
  level=require
# NAT bypass — трафик между офисами не натится
/ip/firewall/nat/add \
  chain=srcnat \
  src-address=192.168.10.0/24 \
  dst-address=192.168.20.0/24 \
  action=accept \
  comment="IPsec: no NAT to Branch" \
  place-before=0
/ip/firewall/nat/add \
  chain=srcnat \
  src-address=192.168.20.0/24 \
  dst-address=192.168.10.0/24 \
  action=accept \
  comment="IPsec: no NAT to HQ" \
  place-before=0
/ip/firewall/filter/add \
  chain=input \
  protocol=udp \
  dst-port=500,4500 \
  action=accept \
  comment="Allow IKE and NAT-T" \
  place-before=0

/ip/firewall/filter/add \
  chain=input \
  protocol=ipsec-esp \
  action=accept \
  comment="Allow IPsec ESP" \
  place-before=0
/ip/firewall/filter/add \
  chain=forward \
  src-address=192.168.10.0/24 \
  dst-address=192.168.20.0/24 \
  ipsec-policy=in,ipsec \
  action=accept \
  comment="Allow IPsec forward from HQ to Branch"

/ip/firewall/filter/add \
  chain=forward \
  src-address=192.168.20.0/24 \
  dst-address=192.168.10.0/24 \
  ipsec-policy=in,ipsec \
  action=accept \
  comment="Allow IPsec forward from Branch to HQ"
Без NAT-T:  IP → ESP (protocol 50)          — не проходит NAT
С NAT-T:    IP → UDP:4500 → ESP             — проходит NAT
/ip/ipsec/active-peers/print detail
/system/resource/print
/ip/ipsec/profile/set ike2-profile \
  dh-group=ecp256 \
  enc-algorithm=aes-256 \
  hash-algorithm=sha256

/ip/ipsec/proposal/set ike2-proposal \
  enc-algorithms=aes-256-gcm \
  pfs-group=ecp256 \
  lifetime=1h
# С роутера Офиса A — пинг устройства в Офисе B
/ping 192.168.20.1 src-address=192.168.10.1 count=5
/ip/ipsec/active-peers/print detail
0   peer=peer-branch state=established
     local-address=203.0.113.10 remote-address=198.51.100.20
     side=initiator uptime=2h15m30s
     ph2-total=1 natt-peer=no
     established=mar/15/2026 10:30:15
/ip/ipsec/installed-sa/print detail
0   peer=peer-branch direction=in
     src-address=198.51.100.20 dst-address=203.0.113.10
     auth-algorithm=none enc-algorithm=aes-256-gcm
     current-bytes=15234567 current-packets=10234
     add-lifetime=30m/25m12s replay-size=64
     state=mature hw-aead=yes

 1   peer=peer-branch direction=out
     src-address=203.0.113.10 dst-address=198.51.100.20
     auth-algorithm=none enc-algorithm=aes-256-gcm
     current-bytes=12345678 current-packets=8765
     add-lifetime=30m/25m12s replay-size=64
     state=mature hw-aead=yes
/ip/ipsec/policy/print stats
# Счётчики на policy
/ip/ipsec/policy/print stats

# Трафик через туннель в реальном времени
/tool/torch interface=ether1 src-address=192.168.10.0/24 dst-address=192.168.20.0/24
/system/logging/add topics=ipsec action=memory
/log/print where topics~"ipsec"
/system/logging/remove [find where topics~"ipsec"]
/ip/ipsec/peer/add \
  name=peer-office-c \
  address=192.0.2.50/32 \
  profile=ike2-profile \
  exchange-mode=ike2

/ip/ipsec/identity/add \
  peer=peer-office-c \
  auth-method=pre-shared-key \
  secret="aB3@kL9#mN5$pQ7&rT1!vX4%yZ8wF2h"

/ip/ipsec/policy/add \
  peer=peer-office-c \
  src-address=192.168.10.0/24 \
  dst-address=192.168.30.0/24 \
  tunnel=yes \
  sa-src-address=203.0.113.10 \
  sa-dst-address=192.0.2.50 \
  proposal=ike2-proposal \
  action=encrypt \
  level=require

/ip/firewall/nat/add \
  chain=srcnat \
  src-address=192.168.10.0/24 \
  dst-address=192.168.30.0/24 \
  action=accept \
  comment="IPsec: no NAT to Office C" \
  place-before=0
# Создаём CA
/certificate/add name=ipsec-ca common-name="IPsec CA" \
  key-size=2048 days-valid=3650 key-usage=key-cert-sign,crl-sign
/certificate/sign ipsec-ca

# Сертификат для Офиса A
/certificate/add name=cert-hq common-name="HQ-Router" \
  key-size=2048 days-valid=1825 \
  key-usage=digital-signature,key-encipherment,tls-client
/certificate/sign cert-hq ca=ipsec-ca

# Сертификат для Офиса B
/certificate/add name=cert-branch common-name="Branch-Router" \
  key-size=2048 days-valid=1825 \
  key-usage=digital-signature,key-encipherment,tls-client
/certificate/sign cert-branch ca=ipsec-ca
/certificate/export-certificate cert-branch export-passphrase="ExportPass123"
/certificate/export-certificate ipsec-ca
/certificate/import file-name=ipsec-ca.crt
/certificate/import file-name=cert-branch.crt passphrase="ExportPass123"
/certificate/import file-name=cert-branch.key passphrase="ExportPass123"
# Офис A
/ip/ipsec/identity/set [find peer=peer-branch] \
  auth-method=digital-signature \
  certificate=cert-hq \
  remote-certificate=cert-branch

# Офис B
/ip/ipsec/identity/set [find peer=peer-hq] \
  auth-method=digital-signature \
  certificate=cert-branch \
  remote-certificate=cert-hq
# Сравните вывод на обоих роутерах
/ip/ipsec/profile/print detail where name=ike2-profile
/ip/ipsec/proposal/print detail where name=ike2-proposal
# Проверьте порядок NAT-правил
/ip/firewall/nat/print

# Правило accept для IPsec-подсетей должно быть ПЕРЕД masquerade
/ip/ipsec/policy/print
# Проверка NAT-T
/ip/ipsec/active-peers/print
# Если natt-peer=yes — NAT-T активен, значит NAT обнаружен
/ip/ipsec/peer/set peer-branch address=0.0.0.0/0
# Проверка загрузки CPU
/system/resource/print
# Посмотрите cpu-load в процентах
# Переместите policy вверх
/ip/ipsec/policy/move [find where dst-address=192.168.20.0/24] 0
/ip/firewall/mangle/add \
  chain=forward \
  protocol=tcp \
  tcp-flags=syn \
  ipsec-policy=in,ipsec \
  action=change-mss \
  new-mss=1360 \
  passthrough=yes \
  comment="IPsec: clamp MSS"