Проблема с не поднятием ipsec
-
@rodley
Жаль. Оч. часто это помогает. Иначе в будущем могут вылезти и др. проблемы. Двойной NAT - штука опасная (Оф. дока https://www.draytek.com/support/knowledge-base/5428
Попробуйте сменить тип шифрования на 3DES, если у вас оно на AES сейчас живет.
Общая и обязательная рекомендация - смотрите логи в момент проблемы. Всегда и везде, где это возможно.
-
@Konstanti said in Проблема с не поднятием ipsec:
как вариант поиграться с lifetime фазы 1 , чтобы инициировал обмен ключей Drytec (те его lifetime фазы 1 должен быть меньше чем lifetime фазы 1 strongswan pfsense)
Именно фазы 1, не фазы 2? Фаза 1 и там и там установлена сейчас 28800 сек, фаза 2 - 3600 сек .
-
@werter
Да, шифрование 3DES установлено. ПО на драйтеке последнее, свежее пока нету. -
@rodley
Проблема возникает тогда , когда идет обновление ключей фазы 1
По крайней мере , у меня так было
Посмотрите логи , кто являлся инициатором обмена ключей , когда начинают плодиться SA.
У меня четко было видно , как это происходит
Почему так происходит - я пока не разобрался
Я не утверждаю , что это поможет , но все-таки возможно и такое
Есть еще вот такая опция у Strongswan-а
Некоторые советуют ее , но мне не помогла
Она работает только в том случае , если обе стороны поддерживают эту опцию -
@rodley
Попробуйте настройки отсюда www.cyberciti.biz/faq/howto-site-to-site-ipsec-vpn-between-cisco-openbsd-router-pfsense/ -
@rodley Специально посмотрел сейчас старые логи
Там где инициатором обмена ключей был Strongswan PFSense, там и плодились SA
Попробуйте все-таки поиграться с lifetime фазы 1 , мб поможет
Напишите потом , помогло или нет -
@Konstanti said in Проблема с не поднятием ipsec:
@rodley Специально посмотрел сейчас старые логи
Там где инициатором обмена ключей был Strongswan PFSense, там и плодились SA
Попробуйте все-таки поиграться с lifetime фазы 1 , мб поможет
Напишите потом , помогло или нетНет, не помогло. Но по итогу получилось настроить модем в режиме моста и поднять соединение на Draytek. После этого проблем не было, туннель поднялся без вопросов.
-
Добрый.
@rodley
Как говорится, ЧиТД. Здраво )Зы. ПО на модеме перед этим обновили? ) На будущее, т.с.
-
@rodley Покажите логи момента обмена ключами со стороны Strongswan, когда проявится проблема (если проявится )
Но , по-моему, это "глюк" strongswan-а какой-то
Я видел много сообщений в разделе IPSEC , где были несколько SA при одинаковых селекторах трафика . -
Там для настройки ipsec нужно пробрасывать не только порты, но и протокол + делать статик нат на порт. В его связке АДСЛ-модем в режиме роутера, возможно, ломал эту схему. В режиме же бриджа он этому не мешает.
Зы. И снова начинаете решение ТЗ со сложного (
-
@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 для замены ключевого материала без каких-либо перерывов
Об этой опции я писал выше
-
@rodley
Еще в догонку
Попробуйте вот такую опцию в настройках фазы 1
Тогда по уму не должны удаляться CHILD_SA при обновлении ключей IKE_SA
-
@werter
Нет, ПО я не обновлял, модем провайдерский и в другой стране. У меня там только Draytek стоит за этим модемом. Но там ещё и интернет говно :(