Проблема с не поднятием ipsec

Konstanti

@rodley
Проблема возникает тогда , когда идет обновление ключей фазы 1
По крайней мере , у меня так было
Посмотрите логи , кто являлся инициатором обмена ключей , когда начинают плодиться SA.
У меня четко было видно , как это происходит
Почему так происходит - я пока не разобрался
Я не утверждаю , что это поможет , но все-таки возможно и такое
Есть еще вот такая опция у Strongswan-а

Некоторые советуют ее , но мне не помогла
Она работает только в том случае , если обе стороны поддерживают эту опцию

werter

@rodley
Попробуйте настройки отсюда www.cyberciti.biz/faq/howto-site-to-site-ipsec-vpn-between-cisco-openbsd-router-pfsense/

Konstanti

@rodley Специально посмотрел сейчас старые логи

Там где инициатором обмена ключей был Strongswan PFSense, там и плодились SA
Попробуйте все-таки поиграться с lifetime фазы 1 , мб поможет
Напишите потом , помогло или нет

rodley

@Konstanti

@Konstanti said in Проблема с не поднятием ipsec:

@rodley Специально посмотрел сейчас старые логи

Там где инициатором обмена ключей был Strongswan PFSense, там и плодились SA
Попробуйте все-таки поиграться с lifetime фазы 1 , мб поможет
Напишите потом , помогло или нет

Нет, не помогло. Но по итогу получилось настроить модем в режиме моста и поднять соединение на Draytek. После этого проблем не было, туннель поднялся без вопросов.

werter

Добрый.
@rodley
Как говорится, ЧиТД. Здраво )

Зы. ПО на модеме перед этим обновили? ) На будущее, т.с.

Konstanti

@rodley Покажите логи момента обмена ключами со стороны Strongswan, когда проявится проблема (если проявится )
Но , по-моему, это "глюк" strongswan-а какой-то
Я видел много сообщений в разделе IPSEC , где были несколько SA при одинаковых селекторах трафика .

werter

@Konstanti

Там для настройки ipsec нужно пробрасывать не только порты, но и протокол + делать статик нат на порт. В его связке АДСЛ-модем в режиме роутера, возможно, ломал эту схему. В режиме же бриджа он этому не мешает.

Зы. И снова начинаете решение ТЗ со сложного (

Konstanti

@werter Как может модем ломать что-то , если Strongswan сам чудит
Вот лог появления 3-х SA (часть лога вырезана)

Oct 24 00:13:26 11[ENC] <337> parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH N(USE_TRANSP) N(ESP_TFC_PAD_N) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) 
Установлена первая SA
Oct 24 00:13:26 11[IKE] <es_ru_pfsense_ecdsa|337> IKE_SA es_ru_pfsense_ecdsa[337] state change: CONNECTING => ESTABLISHED
Oct 24 00:13:26 11[IKE] <es_ru_pfsense_ecdsa|337> CHILD_SA es_ru_pfsense_ecdsa{2570} established with SPIs ca31a2fd_i ca277f42_o and TS XXX === XXX
Пришел запрос на создание второй SA
Oct 24 00:13:27 13[NET] <es_ru_pfsense_ecdsa|337> received packet: from XXXXXX[500] to XXXXXXX[500] (224 bytes)
Oct 24 00:13:27 13[ENC] <es_ru_pfsense_ecdsa|337> parsed CREATE_CHILD_SA request 2 [ N(USE_TRANSP) N(ESP_TFC_PAD_N) SA No TSi TSr ]
Oct 24 00:13:27 13[IKE] <es_ru_pfsense_ecdsa|337> CHILD_SA es_ru_pfsense_ecdsa{2571} established with SPIs cb52e82b_i c721a072_o and TS XXXXXXX === XXXXXX
Oct 24 00:13:27 13[ENC] <es_ru_pfsense_ecdsa|337> generating CREATE_CHILD_SA response 2 [ N(USE_TRANSP) SA No TSi TSr ]
И вот пришел третий запрос на создание SA
Oct 24 00:13:27 11[ENC] <es_ru_pfsense_ecdsa|337> parsed CREATE_CHILD_SA request 3 [ N(USE_TRANSP) N(ESP_TFC_PAD_N) SA No TSi TSr ]
Oct 24 00:13:27 11[IKE] <es_ru_pfsense_ecdsa|337> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Oct 24 00:13:27 11[IKE] <es_ru_pfsense_ecdsa|337> CHILD_SA es_ru_pfsense_ecdsa{2572} established with SPIs c33b831c_i c84314cd_o and TS XXXXXXX === XXXXXXX

Те вот так на ровном месте при обновлении ключей фазы 1 Strongswan создает 3 SA
Возможно этому есть какое-то логическое объяснение , но я пока с этим не разбирался
Пошел более простым путем
Но явно ноги растут от инициатора

Вот перевод от разработчика Strongswan

Это известная проблема, если вы объединяете break-before-make reauthentication с политиками trap. Существует короткое время после того, как старый SA был прекращен, и в то время как новый установлен, в течение которого никакой SA не установлен в ядре. Но так как политики ловушек все еще установлены, новые приобретения могут быть вызваны ядром, если в это время произойдет совпадение трафика, что создаст дополнительный CHILD_SA (который, в свою очередь, будет воссоздан во время следующей повторной проверки подлинности). Чтобы избежать этого, либо используйте make-before-break reauthentication (создает новое перекрытие IKE и CHILD_SAs), либо просто используйте IKE_SA rekeying для замены ключевого материала без каких-либо перерывов

Об этой опции я писал выше

Konstanti

@rodley
Еще в догонку
Попробуйте вот такую опцию в настройках фазы 1

Тогда по уму не должны удаляться CHILD_SA при обновлении ключей IKE_SA

rodley

@werter
Нет, ПО я не обновлял, модем провайдерский и в другой стране. У меня там только Draytek стоит за этим модемом. Но там ещё и интернет говно :(