Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Странные ошибки IPsec при попытке подключения L2TP/IPsec с Draytek

    Странные ошибки IPsec при попытке подключения L2TP/IPsec с Draytek

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Странные ошибки IPsec при попытке подключения L2TP/IPsec с Draytek, RouterOS
     
    pe1chl
    Guest
    #1
    0
    15.12.2017 19:41:00
    После того, как один из пользователей нашей сети пожаловался, что не может подключиться, несмотря на все попытки, используя роутер Draytek для настройки L2TP/IPsec, я решил достать из закромов свой старый роутер Draytek и попробовать сам. На роутере MikroTik я настроил сервис L2TP/IPsec с практически всеми параметрами по умолчанию. Множество пользователей подключаются через L2TP клиент с IPsec секретом (и логином/паролем) с роутеров MikroTik, и из опыта знаю, что такая же конфигурация работает и на Android и других устройствах. Поэтому я установил последнюю прошивку на свой Draytek 2860n+ и настроил “LAN2LAN VPN” с L2TP/IPsec.

    По умолчанию это вообще не работает, но после того, как в расширенных настройках поставил AES128_SHA1_G2 для фазы 1 и AES128_SHA1 для фазы 2, хотя бы устанавливается фаза 1. На стороне MikroTik фаза 2 SA принимается (судя по отладочному логу), и сессия застревает в состоянии «msg1 sent», после чего в логах появляются сообщения о повторной отправке пакетов. В логе Draytek появляется следующее сообщение (с исправленной орфографией):

    [IPSEC/IKE][L2L][profilename][remote IP] malformed payload: Parse error: byte 7 of ISAKMP NAT-OA Payload must be zero, but is not

    Интересно, что Google выдаёт несколько упоминаний такой ошибки в совершенно других условиях (без MikroTik или Draytek, но с программой Strongswan). Некоторые сообщения довольно старые, но я так и не нашёл подсказок, что именно вызывает проблему и на чьей стороне она… (то есть байт не нулевой на стороне отправителя, в нашем случае MikroTik, и получатель правильно жалуется, или получателю просто стоило бы игнорировать этот ненулевой байт? Может, это вызвано ошибкой в настройках?)

    Есть кто с опытом решения подобных проблем?
     
     
     
    GeorgeHibberd
    Guest
    #2
    0
    30.01.2018 22:56:00
    Привет, у меня такая же проблема с Mikrotik и DrayTek. Ты случайно не нашёл решение?
     
     
     
    GeorgeHibberd
    Guest
    #3
    0
    31.01.2018 12:46:00
    Привет, у меня такая же проблема — не появляется Phase 2, туннель работает нормально, если не использовать шифрование. Я настроил L2TP с телефона и ноутбука, и шифрование тут запускается без проблем. Ты случайно не нашёл решение? Спасибо!
     
     
     
    sindy
    Guest
    #4
    0
    03.02.2018 21:49:00
    Если можно обойтись без L2TP и использовать чистый IPsec с политиками, этот способ точно работает и с Mikrotik, и с Draytek по публичному IP. Те Draytek, с которыми мне приходилось иметь дело, не поддерживали NAT-T.
     
     
     
    pe1chl
    Guest
    #5
    0
    03.02.2018 21:58:00
    Нет, я ещё не решил эту проблему. Думаю, с NAT-T это не сработает, а удобно протестировать я могу только с роутером Draytek за NAT. Draytek это поддерживает, но, по всей видимости, где-то есть баг. Простая IPsec туннель здесь не подходит, потому что удалённая сторона с динамическим адресом.
     
     
     
    pe1chl
    Guest
    #6
    0
    14.07.2018 11:47:00
    Я обновил прошивку Draytek до версии 3.8.9.1 и RouterOS до 6.42.5, но ситуация осталась прежней. Седьмой байт полезной нагрузки ISAKMP NAT-OA должен быть равен нулю, но это не так. Это что-то, что MikroTik может исправить?
     
     
     
    sindy
    Guest
    #7
    0
    14.07.2018 12:15:00
    Это сообщение из лога Draytek или Mikrotik?
     
     
     
    pe1chl
    Guest
    #8
    0
    14.07.2018 13:02:00
    Это в журнале Draytek. Это происходит только при работе через NAT. MikroTik считает, что всё в порядке, и записывает в лог «пакет повторно отправлен x.x.x.x[4500]». Мне удалось подключить Draytek к публичному IP, и теперь я могу настроить рабочее L2TP/IPsec-соединение с MikroTik! Но я думаю, что Draytek обычно поддерживает NAT-T, по крайней мере, он пытается использовать UDP порт 4500 и так далее. Значит, есть какая-то несовместимость.
     
     
     
    sindy
    Guest
    #9
    0
    14.07.2018 15:53:00
    Из RFC 3947: Формат пакета NAT-OA следующий:  
    1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8  
          +---------------+---------------+---------------+---------------+  
          | Next Payload  | RESERVED      | Длина полезной нагрузки       |  
          +---------------+---------------+---------------+---------------+  
          | Тип идентификатора | RESERVED  | RESERVED                      |  
          +---------------+---------------+---------------+---------------+  
          |           IPv4 (4 октета) или IPv6-адрес (16 октетов)          |  
          +---------------+---------------+---------------+---------------+  

    Тип полезной нагрузки для NAT original address payload — 21. Тип идентификатора определён в [RFC2407]. Разрешены только типы ID_IPV4_ADDR и ID_IPV6_ADDR. Два зарезервированных поля после типа идентификатора должны быть равны нулю.

    Я взял лог ipsec на клиенте Mikrotik ipsec-l2tp, который находится за NAT (потому что NAT-OA полезная нагрузка уже передаётся на зашифрованном этапе Фазы 1, а лог показывает расшифрованное содержимое только для принимаемых пакетов), и сервер Mikrotik отправляет следующее:  
    1500000c 011106a5 c0a80a58  
    1500000c 01001194 0a000005  
    0000000c 01001194 c0a80a58  

    0x15 = тип полезной нагрузки, 21  
    0x00 = зарезервировано, правильно  
    0x000c = длина записи, правильно  
    0x01 = IPv4  
    0x001194 явно не 0x000000.  

    Однако RFC2407, на который ссылается RFC3947, подразумевает другой формат полезной нагрузки, который содержит ссылку на тип ID — это Identification Payload:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      | Next Payload  |   RESERVED    |        Payload Length         |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |   ID Type     |  Protocol ID  |             Port              |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      ~                     Identification Data                       ~  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

    Если интерпретировать 0x1106a5 таким образом, то:  
    0x0 = IPv6 HOPOPT, вероятно, неактуально  
    0x1194 = 4500 = альтернативный (NAT-T) ISAKMP порт  

    Для меня это явный баг у Mikrotik, где ребята повторно используют уже подготовленное содержимое полезной нагрузки (поскольку в обоих случаях IP-адрес занимает последние 4 байта полезной нагрузки), но забывают применить маску с ID type перед отправкой с 0xFF000000.  

    Единственный недостаток — я провёл тест на версии 6.42.1, запущенной на сервере, но думаю, что это не будет большой проблемой, когда вы отправите это на support@mikrotik.com.
     
     
     
    pe1chl
    Guest
    #10
    0
    14.07.2018 16:39:00
    Спасибо за отладку. Значит, это действительно то, что нужно исправить на стороне MikroTik, чтобы соответствовать стандартам. Похоже, что используемый IPsec-код не проверяет это условие. Возможно, это причина других проблем с L2TP/IPsec… По моим поискам, кажется, что Strongswan когда-то сталкивался с этой проблемой и уже исправил её, но, возможно, MikroTik использует устаревшую версию? Я сообщил об этом в службу поддержки.
     
     
     
    sindy
    Guest
    #11
    0
    14.07.2018 16:57:00
    Я бы скорее сказал «основано на старой версии», учитывая, как быстро тамошние ребята отреагировали на некоторые мои недавние утверждения, но боюсь, что единственный логичный следующий шаг — отправить это в службу поддержки. Вас это касается — вы и отправляйте. Все Draytek, с которыми я встречался, были удалёнными, так что я не смог бы проверить предложенное решение лично.
     
     
     
    pe1chl
    Guest
    #12
    0
    14.07.2018 17:01:00
    Я сообщил в поддержку по этой теме. Посмотрим, что из этого выйдет... У меня примерно такая же ситуация: я отлаживаю это для нескольких людей, которые хотят подключиться к моему серверу, и достал свой старый Draytek из коробки с хламом ради этого. Когда стоишь за другим роутером (MikroTik) с NAT — не работает, но потом я вспомнил про 4G SIM-карту и USB-модем, которые выдают прямой IP-адрес, и с таким подключением на Draytek удалось соединиться (без NAT-T). Значит, остальные части IPsec и L2TP между собой взаимодействуют нормально.
     
     
     
    sindy
    Guest
    #13
    0
    15.07.2018 19:27:00
    Даже диссектор ISAKMP в Wireshark не утруждает себя проверкой того, что содержимое зарезервированных байтов (RESERVED) в NAT-OA полезной нагрузке равно 0x00 0x0000. Используйте «Import from Hex Dump» с приведёнными данными и UDP-заголовком-затычкой с исходным портом 500:

    0000 cf 79 93 70 33 48 f6 07 b9 3a 53 64 df f8 e5 c1  
    0010 08 10 20 00 d0 7a f8 56 00 00 00 bc 01 00 00 18  
    0020 bb dc 22 3a 45 e4 40 a6 08 cd c9 f9 f7 63 30 d8  
    0030 7d d3 4e e3 0a 00 00 34 00 00 00 01 00 00 00 01  
    0040 00 00 00 28 01 03 04 01 05 13 62 b2 00 00 00 1c  
    0050 03 0c 00 00 80 01 00 01 80 02 07 08 80 04 00 04  
    0060 80 06 01 00 80 05 00 02 05 00 00 1c d6 3a 6d 7e  
    0070 34 48 22 07 48 54 d9 1a cd 39 39 fc 5b 8f 2c ee  
    0080 06 9b bc a6 05 00 00 0c 01 11 06 a5 c0 a8 05 ad  
    0090 15 00 00 0c 01 11 06 a5 c0 a8 0a 58 15 00 00 0c  
    00a0 01 00 11 94 0a 00 00 05 00 00 00 0c 01 00 11 94  
    00b0 c0 a8 0a 58 61 b3 4e 5d 7b 4c 7d 07
     
     
     
    sindy
    Guest
    #14
    0
    16.07.2018 06:45:00
    Если подумать, это могло быть хитрым способом сказать удалённой стороне, на каком порту я слушаю, используя, казалось бы, незанятое место в существующем параметре, а Draytek всё испортил, проверяя эти нули.
     
     
     
    pe1chl
    Guest
    #15
    0
    16.07.2018 07:48:00
    Создан тикет #2018071422001752 по этой проблеме. Конечно, есть ещё один нюанс: реализация MikroTik не позволяет обслуживать больше одного L2TP/IPsec клиента за NAT с одинаковым удалённым IP. Это частая жалоба, особенно когда пытаются настроить VPN с нескольких мобильных устройств, подключающихся через одного мобильного провайдера с CGNAT. Я также заметил, что стандартная настройка сервера с IPsec в режиме «порт строгий» некорректно работает при двух уровнях NAT в цепочке. Настройка индивидуального IPsec пира с «перезаписью порта» решает эту проблему. Возможно, это связано, и/или решение этой проблемы поможет и с этим.
     
     
     
    sindy
    Guest
    #16
    0
    16.07.2018 08:01:00
    Нестандартное население NAT-OA ISAKMP полезной нагрузки не связано с проблемой «множественных клиентов L2TP/IPsec за одним NAT». Корень этой проблемы и работающее решение описаны здесь.
     
     
     
    pe1chl
    Guest
    #17
    0
    16.07.2018 08:13:00
    Ок, спасибо. Я подумал, что поля в пакете NAT-OA могут быть частью неполного решения, чтобы обойти эту проблему.
     
     
     
    pe1chl
    Guest
    #18
    0
    15.08.2018 11:15:00
    Проблема была решена в версии 6.43rc56. Так что, когда выйдет стабильная версия 6.43, мы её установим и сможем использовать этот протокол на роутерах Draytek.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры