Mikrotik.moscow [тема: Редкие несоответствия ключей SA между strongSwan и RouterOS]

Редкие несоответствия ключей SA между strongSwan и RouterOS

Wed, 08 Apr 2020 09:36:00 -0400

Редкие несоответствия ключей SA между strongSwan и RouterOS RouterOS в форуме RouterOS.
Конечно, я открыл тикет полтора года назад) Это проблема взаимодействия между mikrotik и strongswan при использовании PFS. Отключение PFS — плохое решение. Если правильно помню, когда я разбирался с этой проблемой, я также пробовал другую реализацию.
08.04.2020 09:36:00, sergeyk.

Редкие несоответствия ключей SA между strongSwan и RouterOS

Wed, 08 Apr 2020 09:15:00 -0400

Редкие несоответствия ключей SA между strongSwan и RouterOS RouterOS в форуме RouterOS.
Ты уже открывал заявку в службу поддержки support@mikrotik.com, как я советовал полтора года назад? В твоей конфигурации проблема возникает между двумя Mikrotik или между Mikrotik с одной стороны и каким-то другим IKEv2-решением с другой? За всё это время я не встречал ни одного случая такой проблемы на примерно 20 IKEv2-связях (хотя это не значит, что их нет, но при сбое на 30 минут на большинстве связей сразу бы сработал сигнал тревоги), многие из них с несколькими параллельными SA. Так что, возможно, это связано с твоей аппаратной платформой или с взаимодействием с другим IKEv2-решением… Разработчикам Mikrotik нужны все эти детали, чтобы они могли воспроизвести проблему в лаборатории и исправить её.
08.04.2020 09:15:00, sindy.

Редкие несоответствия ключей SA между strongSwan и RouterOS

Wed, 08 Apr 2020 08:49:00 -0400

Редкие несоответствия ключей SA между strongSwan и RouterOS RouterOS в форуме RouterOS.
Прошло полтора года, а проблема всё ещё не решена)
08.04.2020 08:49:00, sergeyk.

Редкие несоответствия ключей SA между strongSwan и RouterOS

Wed, 28 Nov 2018 19:00:00 -0500

Редкие несоответствия ключей SA между strongSwan и RouterOS RouterOS в форуме RouterOS.
Пожалуйста, отправьте это как баг-репорт на support@mikrotik.com, этот форум — не подходящее место. Лично я с таким багом не сталкивался начиная с версии 6.43.2, но все мои IKEv2-сессии идут либо между двумя Mikrotik’ами, либо между Mikrotik и Windows-машиной, где PFS не поддерживается со стороны Windows. Так что теоретически возможно, что с strongswan это ведёт себя иначе.
28.11.2018 19:00:00, sindy.

Редкие несоответствия ключей SA между strongSwan и RouterOS

Wed, 28 Nov 2018 11:30:00 -0500

Редкие несоответствия ключей SA между strongSwan и RouterOS RouterOS в форуме RouterOS.
Похоже, эта проблема так и не исправлена. Я протестировал 6.43.4 и 6.44beta28 с IKEv2 в режиме транспортных предложений: add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1h pfs-group=modp4096 профиль: dh-group=modp4096 dpd-interval=10s dpd-maximum-failures=3 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=2h, подключён к strongswan 5.7.1 на centos7. Всё работает нормально какое-то время, ключи обновляются каждый час, но спустя 2-3 дня ситуация повторяется, как в первом посте: у обеих сторон правильные номера SPI, но ключи аутентификации и шифрования полностью разные, из-за чего весь зашифрованный трафик сбрасывается обеими пирами. В этот момент обе стороны посылают друг другу DPD, так как не видят активности по этой ссылке, но DPD не использует ESP и эти ключи, поэтому для обеих сторон канал выглядит живым и не пересоздаётся аутентификация. Через час при следующем обновлении ключи снова синхронизируются, и трафик течёт. Сегодня поставил 6.44beta39, буду смотреть, как пойдёт, но в списке изменений ничего про обновление ключей не вижу, скорее всего будет точно так же, и это очень раздражает. И, конечно, всё начинает работать, если принудительно вызвать повторную аутентификацию. Есть идеи, в чём может быть причина? Или лучше заявить об этой ошибке в другой трекер?
28.11.2018 11:30:00, sergeyk.

Редкие несоответствия ключей SA между strongSwan и RouterOS

Tue, 11 Sep 2018 20:14:00 -0400

Редкие несоответствия ключей SA между strongSwan и RouterOS RouterOS в форуме RouterOS.
Из темы бета-версии 6.44: Что нового в 6.44beta6 (2018-Сен-11 08:52): … *) ike2 — исправлены редкие ошибки несоответствия ключей аутентификации и шифрования после обновления ключа с включённым PFS; Если у вас есть возможность выделить устройство для тестирования 6.44beta6 с strongswan, было бы супер. Я планирую сделать это на паре Mikrotik через несколько дней — сейчас они заняты тестированием другого. Чем раньше исправление докажет свою стабильность, тем скорее его можно будет внедрить в 6.43.x.
11.09.2018 20:14:00, sindy.

Редкие несоответствия ключей SA между strongSwan и RouterOS

Tue, 21 Aug 2018 15:33:00 -0400

Редкие несоответствия ключей SA между strongSwan и RouterOS RouterOS в форуме RouterOS.
Привет! Мы настроили site-to-site VPN, соединяющий наш главный офис (running strongSwan 5.5.1 на Debian Stretch) с филиалом (используется RB2011iL с RouterOS 6.40.8). Это туннель IKEv2 с PSK и стандартным временем жизни ключа — 1 час. В целом всё работает отлично, но иногда (примерно раз в неделю) при обновлении ключа что-то идёт не так: после рекея две стороны уже не совпадают по тому, какие ключи использовать.

После такого рекея SAs на стороне strongSwan выглядят так:
src dst
proto esp spi 0x09890c39 reqid 2 mode tunnel
replay-window 0 flag af-unspec
auth-trunc hmac(sha256) 0x511...fc4da 128
enc cbc(aes) 0x74a1...9c8c
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

src dst
proto esp spi 0xcff9f231 reqid 2 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha256) 0x162e...3c5f9 128
enc cbc(aes) 0x06ef...2a5
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

В то время как на стороне MikroTik используются следующие SAs:
1 E spi=0x9890C39 src-address= dst-address= state=mature
auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=128
auth-key="3d5138d833aa55ceaee9801707c48a4dfb80e29fdc899cba6e39b188a03bc83b"
enc-key="c30de4b999ba413af5da8d2d8e024001" add-lifetime=48m2s/1h3s replay=128

2 E spi=0xCFF9F231 src-address= dst-address= state=mature
auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=128
auth-key="e9d1eefcb8250c7b5795c381e7c9eb7b44e67064fb1a90334335d372f5efadb3"
enc-key="a856120a0824bb2fc60aa565482d303e" addtime=aug/21/2018 10:18:10 expires-in=51m18s
add-lifetime=48m2s/1h3s current-bytes=35703 current-packets=144 replay=128

Из этого вывода видно, что обе стороны используют разные ключи аутентификации и шифрования для одного и того же SPI. В результате любые ESP-пакеты данного соединения просто сбрасываются с обеих сторон. Перезапуск соединения сразу всё исправляет до следующего раза, когда после рекея возникает рассинхронизация ключей.

Логи рекея на стороне strongSwan не вызывают у меня особого подозрения:
2018-08-21T10:18:09.616057+02:00 09[IKE] queueing CHILD_REKEY task
2018-08-21T10:18:09.616674+02:00 09[IKE] activating new tasks
2018-08-21T10:18:09.617223+02:00 09[IKE] activating CHILD_REKEY task
2018-08-21T10:18:09.617782+02:00 09[IKE] establishing CHILD_SA conn_name{2}
2018-08-21T10:18:09.618394+02:00 09[CFG] proposing traffic selectors for us:
2018-08-21T10:18:09.618955+02:00 09[CFG] 10.11.0.0/16
2018-08-21T10:18:09.619505+02:00 09[CFG] 10.10.0.0/16
2018-08-21T10:18:09.620064+02:00 09[CFG] proposing traffic selectors for other:
2018-08-21T10:18:09.620697+02:00 09[CFG] 10.50.0.0/16
2018-08-21T10:18:09.621381+02:00 09[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
2018-08-21T10:18:09.636466+02:00 09[ENC] generating CREATE_CHILD_SA request 30 [ N(REKEY_SA) SA No KE TSi TSr ]
2018-08-21T10:18:09.637105+02:00 09[NET] sending packet: from [4500] to [4500] (496 bytes)
2018-08-21T10:18:10.571371+02:00 12[NET] received packet: from [4500] to [4500] (480 bytes)
2018-08-21T10:18:10.572847+02:00 12[ENC] parsed CREATE_CHILD_SA response 30 [ No KE TSi TSr SA ]
2018-08-21T10:18:10.590638+02:00 12[CFG] selecting proposal:
2018-08-21T10:18:10.591675+02:00 12[CFG] proposal matches
2018-08-21T10:18:10.592406+02:00 12[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
2018-08-21T10:18:10.593170+02:00 12[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
2018-08-21T10:18:10.593884+02:00 12[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
2018-08-21T10:18:10.594612+02:00 12[CFG] selecting traffic selectors for us:
2018-08-21T10:18:10.595126+02:00 12[CFG] config: 10.11.0.0/16, received: 10.10.0.0/16 => no match
2018-08-21T10:18:10.595605+02:00 12[CFG] config: 10.10.0.0/16, received: 10.10.0.0/16 => match: 10.10.0.0/16
2018-08-21T10:18:10.596273+02:00 12[CFG] selecting traffic selectors for other:
2018-08-21T10:18:10.596780+02:00 12[CFG] config: 10.50.0.0/16, received: 10.50.0.0/16 => match: 10.50.0.0/16
2018-08-21T10:18:10.597258+02:00 12[CHD] using AES_CBC for encryption
2018-08-21T10:18:10.597731+02:00 12[CHD] using HMAC_SHA2_256_128 for integrity
2018-08-21T10:18:10.598220+02:00 12[CHD] adding inbound ESP SA
2018-08-21T10:18:10.598695+02:00 12[CHD] SPI 0xcff9f231, src dst
2018-08-21T10:18:10.599168+02:00 12[CHD] adding outbound ESP SA
2018-08-21T10:18:10.599642+02:00 12[CHD] SPI 0x09890c39, src dst
2018-08-21T10:18:10.600129+02:00 12[IKE] CHILD_SA conn_name{26} established with SPIs cff9f231_i 09890c39_o and TS 10.10.0.0/16 === 10.50.0.0/16
2018-08-21T10:18:10.600670+02:00 12[IKE] reinitiating already active tasks
2018-08-21T10:18:10.601294+02:00 12[IKE] CHILD_REKEY task
2018-08-21T10:18:10.601800+02:00 12[IKE] closing CHILD_SA conn_name{21} with SPIs cca08482_i (29988 bytes) 0f456b61_o (47112 bytes) and TS 10.10.0.0/16 === 10.50.0.0/16
2018-08-21T10:18:10.602274+02:00 12[IKE] sending DELETE for ESP CHILD_SA with SPI cca08482
2018-08-21T10:18:10.602744+02:00 12[ENC] generating INFORMATIONAL request 31 [ D ]
2018-08-21T10:18:10.603211+02:00 12[NET] sending packet: from [4500] to [4500] (80 bytes)
2018-08-21T10:18:10.605572+02:00 08[NET] received packet: from [4500] to [4500] (96 bytes)
2018-08-21T10:18:10.606048+02:00 08[ENC] parsed INFORMATIONAL response 31 [ ]
2018-08-21T10:18:10.606520+02:00 08[IKE] CHILD_SA closed
2018-08-21T10:18:10.607076+02:00 08[IKE] activating new tasks
2018-08-21T10:18:10.607624+02:00 08[IKE] ничего инициировать не нужно

К сожалению, логов с RouterOS у меня сейчас нет. У кого-нибудь уже была похожая ситуация? Как я сказал, эту проблему сложно отследить, поскольку она появляется редко, и я не смог найти способ её воспроизвести. Любые советы будут очень полезны.
21.08.2018 15:33:00, dorian.