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



  • Есть 2 офиса, в одном стоит pfSense 2.4.4 , в другом стоит Draytek 2960.
    Draytek стоит за adsl роутером провайдера. Настроен IPsec тоннель между draytek и pfSense. pfSense в роли ответчика, IKEv2, NAT-T на Draytek включен. Периодически происходит поднятие еще нескольких фаз 2, после чего трафик перестает ходить. Как с этим бороться?



  • Добрый.

    Обновить ПО на Драйтеке.
    АДСЛ модем перевести в режим bridge. Пусть Драйтек поднимает линк. Плодить сущности в виде двойного НАТ-а не стоит.



  • @rodley
    Здр
    По какой-то причине при обновлении ключей фазы 1 иногда Strongswan создает несколько child_sa.
    Так как была похожая проблема поборол ее так
    написал маленькую программу , которая использует протокол vici

    https://www.strongswan.org/apidoc/md_src_libcharon_plugins_vici_README.html

    Теперь при наступлении события child-updown программа проверяет , сколько записей находится в SADB после обновления ключей .
    Если записей больше 1 , то программа посылает сигнал strongswan-у на удаление определенной записи из списка соединений

    Выглядит это приблизительно так (создались SA 863 и 865) - 863 удаляется

    Oct 24 01:13:26 Received command "FIND"
    Oct 24 01:13:26 Child SA is UP, SA uniquied is #863,IKE uniqueid is #127,number of active SA: 1
    Oct 24 01:13:26 Waiting for connection...
    Oct 24 01:13:27 Accepted connection,receiving data  ....
    Oct 24 01:13:27 Received command "FIND"
    Oct 24 01:13:27 Child SA is UP, SA uniquied is #865,IKE uniqueid is #127,number of active SA: 2
    Oct 24 01:13:27 Accepted connection,receiving data  ....
    Oct 24 01:13:27 Received command "TERM"
    Oct 24 01:13:27 Received packet for delete SA , SA uniqueid #863,IKE uniqueid #127 remote host XXX.XXX.XXX.XXX,local host XXX.XXX.XXX.XXX, spi 0xca31a2fd 
    Oct 24 01:13:27 Child SA with uniqueid #863 found in SADB,deleting...
    Oct 24 01:13:27 [IKE] closing CHILD_SA con2000{863} with SPIs ca277f42_i (0 bytes) ca31a2fd_o (0 bytes) and TS XXX.XXX.XXX.XXX=== XXX.XXX.XXX.XXX
    Oct 24 01:13:27 [IKE] sending DELETE for ESP CHILD_SA with SPI ca277f42
    Oct 24 01:13:27 [ENC] generating INFORMATIONAL request 4 [ D ]
    Oct 24 01:13:27 [NET] sending packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (80 bytes)
    Oct 24 01:13:27 [NET] received packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (80 bytes)
    Oct 24 01:13:27 [ENC] parsed INFORMATIONAL response 4 [ D ]
    Oct 24 01:13:27 [IKE] received DELETE for ESP CHILD_SA with SPI ca31a2fd
    Oct 24 01:13:27 [IKE] CHILD_SA closed
    Oct 24 01:13:27 SA with uniqueid 863 has deleted successfully
    Oct 24 01:13:27 Waiting for connection...
    
    

    как вариант поиграться с lifetime фазы 1 , чтобы инициировал обмен ключей Drytec (те его lifetime фазы 1 должен быть меньше чем lifetime фазы 1 strongswan pfsense)



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

    Добрый.

    Обновить ПО на Драйтеке.
    АДСЛ модем перевести в режим bridge. Пусть Драйтек поднимает линк. Плодить сущности в виде двойного НАТ-а не стоит.

    Увы, это проблема.



  • @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-а
    6ff9c3c0-e6ae-424f-b1ae-0b22836d1782-image.png

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





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

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



  • @Konstanti

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

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

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

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



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

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



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



  • @Konstanti

    Там для настройки 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
    5984a9ca-516e-4fe2-a3e1-b3329accb3e0-image.png

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



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


Log in to reply