Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Russian
    17 Posts 3 Posters 1.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      rodley @werter
      last edited by rodley

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

      1 Reply Last reply Reply Quote 0
      • K
        Konstanti @rodley
        last edited by Konstanti

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

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

        1 Reply Last reply Reply Quote 0
        • werterW
          werter
          last edited by werter

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

          1 Reply Last reply Reply Quote 0
          • K
            Konstanti @rodley
            last edited by Konstanti

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

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

            R 1 Reply Last reply Reply Quote 0
            • R
              rodley @Konstanti
              last edited by

              @Konstanti

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

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

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

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

              werterW K 3 Replies Last reply Reply Quote 1
              • werterW
                werter @rodley
                last edited by werter

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

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

                R 1 Reply Last reply Reply Quote 0
                • K
                  Konstanti @rodley
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • werterW
                    werter
                    last edited by werter

                    @Konstanti

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

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

                    K 1 Reply Last reply Reply Quote 0
                    • K
                      Konstanti @werter
                      last edited by 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 для замены ключевого материала без каких-либо перерывов

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

                      1 Reply Last reply Reply Quote 0
                      • K
                        Konstanti @rodley
                        last edited by

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

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

                        1 Reply Last reply Reply Quote 0
                        • R
                          rodley @werter
                          last edited by

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

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.