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

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

  • R

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

    0
    K
     1 Reply

  • Добрый.

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

    0
    R
     1 Reply
  • K

    @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)

    0
    R
     1 Reply
  • R

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

    Добрый.

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

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

    0 1 Reply

  • @rodley
    Жаль. Оч. часто это помогает. Иначе в будущем могут вылезти и др. проблемы. Двойной NAT - штука опасная (

    Оф. дока https://www.draytek.com/support/knowledge-base/5428

    Попробуйте сменить тип шифрования на 3DES, если у вас оно на AES сейчас живет.

    Общая и обязательная рекомендация - смотрите логи в момент проблемы. Всегда и везде, где это возможно.

    0
    R
     1 Reply
  • R

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

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

    Именно фазы 1, не фазы 2? Фаза 1 и там и там установлена сейчас 28800 сек, фаза 2 - 3600 сек .

    0
    K
     2 Replies
  • R

    @werter
    Да, шифрование 3DES установлено. ПО на драйтеке последнее, свежее пока нету.

    0
  • K

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

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

    0

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

    0
  • K

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

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

    0
    R
     1 Reply
  • R

    @Konstanti

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

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

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

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

    1
    K
     3 Replies

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

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

    0
    R
     1 Reply
  • K

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

    0

  • @Konstanti

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

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

    0
    K
     1 Reply
  • K

    @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 для замены ключевого материала без каких-либо перерывов

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

    0
  • K

    @rodley
    Еще в догонку
    Попробуйте вот такую опцию в настройках фазы 1
    5984a9ca-516e-4fe2-a3e1-b3329accb3e0-image.png

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

    0
  • R

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

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© 2020 Rubicon Communications, LLC | Privacy Policy