Mikrotik.moscow [тема: sstp-туннели отключаются по таймауту]

sstp-туннели отключаются по таймауту

Wed, 21 May 2014 10:18:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
Похоже, у нас хорошие новости от команды поддержки MK: Спасибо за ваш отчет. Нам удалось воспроизвести проблему и исправить её. Пожалуйста, дождитесь выхода версии 6.14. Так что ждём версию 6.14, и тогда мы сможем закрыть эту тему на форуме.
21.05.2014 10:18:00, DjM.

sstp-туннели отключаются по таймауту

Tue, 20 May 2014 15:06:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
Та же проблема. С тех пор как вышел RouterOS 6.7, SSTP почему-то не работает как надо по нескольким причинам: если используешь NPS (Windows Server 2008 R2) и принудительно включаешь шифрование, SSTP-туннели начинают сбоить, поэтому приходится разрешать отсутствие шифрования для PPTP или других видов туннелей. Я обновился до версии 6.12, и туннель L2TP/IPSec начал самопроизвольно отключать систему, вроде бы без причины, через 10 дней нормальной работы. Сейчас в версии 6.13 соединение падает без объяснений, а клиент Windows 7 при этом вроде бы остаётся в сети. Похоже, что защищённые туннели уже не в почёте у RouterOS.
20.05.2014 15:06:00, MadriSX.

sstp-туннели отключаются по таймауту

Tue, 20 May 2014 10:22:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
Мне удалось зафиксировать проблему между ROS 6.13 и ROS 6.13, я создал файлы поддержки и отправил их в службу поддержки MK через [Ticket#2014051266000793]. Посмотрим, удастся ли продвинуться дальше.
20.05.2014 10:22:00, DjM.

sstp-туннели отключаются по таймауту

Mon, 19 May 2014 13:13:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
@DjM: Пока нет, но это в моём списке дел.
19.05.2014 13:13:00, liquidcz.

sstp-туннели отключаются по таймауту

Mon, 19 May 2014 12:35:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
@liquidcz: Спасибо за ответ. В нашем случае наблюдается похожая ситуация, проблема явно видна. Мне также удалось воспроизвести эту проблему на версии 6.13, поэтому я попробую повторить и отправить информацию службе поддержки MK. Вы уже передавали информацию службе поддержки MK?
19.05.2014 12:35:00, DjM.

sstp-туннели отключаются по таймауту

Mon, 19 May 2014 10:50:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
2DjM: Я использую статические привязки интерфейсов sstp-server. Спасибо.
19.05.2014 10:50:00, liquidcz.

sstp-туннели отключаются по таймауту

Sun, 18 May 2014 17:12:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
@Disassembler, liquidcz: Вы используете привязки интерфейсов sstp-server на стороне сервера или у вас только динамические интерфейсы sstp-server? Я проведу более тщательные тесты в своей среде, и если удастся поймать проблему, сообщу об этом здесь и в службу поддержки.
18.05.2014 17:12:00, DjM.

sstp-туннели отключаются по таймауту

Sun, 18 May 2014 09:01:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
После обновления до версии 6.13 проблема осталась той же. Каждые 60 секунд соединение sstp прерывалось. Отправлялся управляющий пакет типа abort, ответ-эхо не приходил. После того как я снова откатился до версии 6.7, обмен эхо-сообщениями по sstp прошёл нормально, связь не прерывалась.
18.05.2014 09:01:00, liquidcz.

sstp-туннели отключаются по таймауту

Sat, 17 May 2014 07:30:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
Никаких улучшений с версией 6.13 у меня не наблюдается. Похоже, есть какая-то проблема с отправкой ICMP keepalive с серверной стороны. Самое странное, что такое поведение проявляется только у 5-10 клиентов из 100. Я даже пытался сделать сброс настроек на заводские на некоторых из них и заново настроить туннели — это работает какое-то время, но после перезапуска или двух начинается тайм-аут снова.

Клиент на ROS 6.13 с сервером на ROS 6.7
Клиент (ROS 6.13):
08:48:29 sstp,packet SSTP: sstp-out2 отправил управляющий пакет типа: echo request
08:48:29 sstp,packet SSTP: 10 01 00 08 00 08 00 00
08:48:29 sstp,packet SSTP: sstp-out2 получил управляющий пакет типа: echo response
08:48:29 sstp,packet SSTP: 10 01 00 08 00 09 00 00
08:48:29 sstp,packet SSTP: sstp-out2 получил управляющий пакет типа: echo request
08:48:29 sstp,packet SSTP: 10 01 00 08 00 08 00 00
08:48:29 sstp,packet SSTP: sstp-out2 отправил управляющий пакет типа: echo response
08:48:29 sstp,packet SSTP: 10 01 00 08 00 09 00 00

Сервер (ROS 6.7):
08:48:29 sstp,packet SSTP: отправил управляющий пакет типа: echo request
08:48:29 sstp,packet SSTP: 10 01 00 08 00 08 00 00
08:48:29 sstp,packet SSTP: получил управляющий пакет типа: echo request
08:48:29 sstp,packet SSTP: 10 01 00 08 00 08 00 00
08:48:29 sstp,packet SSTP: отправил управляющий пакет типа: echo response
08:48:29 sstp,packet SSTP: 10 01 00 08 00 09 00 00
08:48:29 sstp,packet SSTP: получил управляющий пакет типа: echo response
08:48:29 sstp,packet SSTP: 10 01 00 08 00 09 00 00

Клиент на ROS 6.13 с сервером на ROS 6.13 (или любой другой версии от 6.8 и выше)
Клиент (ROS 6.13):
09:19:15 sstp,packet SSTP: sstp-out2 отправил управляющий пакет типа: echo request
09:19:15 sstp,packet SSTP: 10 01 00 08 00 08 00 00

Сервер (ROS 6.13):
09:19:15 sstp,packet SSTP: получил управляющий пакет типа: echo request
09:19:15 sstp,packet SSTP: 10 01 00 08 00 08 00 00
09:19:15 sstp,packet SSTP: отправил управляющий пакет типа: echo response
09:19:15 sstp,packet SSTP: 10 01 00 08 00 09 00 00
09:19:15 sstp,packet SSTP: отправил управляющий пакет типа: echo request
09:19:15 sstp,packet SSTP: 10 01 00 08 00 08 00 00
17.05.2014 07:30:00, Disassembler.

sstp-туннели отключаются по таймауту

Fri, 16 May 2014 19:13:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
Похоже, что в версии 6.13 устранили проблему с тайм-аутом SSTP. По моим тестам, проблема была связана с привязками интерфейса sstp-server. После обновления с 6.12 до 6.13 проверьте свои правила файрвола, где использовались эти привязки, так как после обновления они отмечались как недействительные (отключение и последующее включение решит проблему).
16.05.2014 19:13:00, DjM.

sstp-туннели отключаются по таймауту

Thu, 15 May 2014 12:34:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
У меня такая же проблема. Когда я понижаю версию до 6.7, все проблемы исчезают. RB450G RB750G RB433AH RB750
15.05.2014 12:34:00, liquidcz.

sstp-туннели отключаются по таймауту

Sun, 11 May 2014 20:26:00 -0400

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
У меня такие же проблемы с «negotiation timeout» в SSTP VPN. Используемые RB: RB951Ui-2HnD, RB433UAH, RB750. Версии ROS: 6.12 — проблема продолжается, 6.7 — с SSTP VPN никаких проблем не было. Конфигурация не менялась до и после обновления с 6.7 на 6.12. Я уже создал [Ticket#2014051266000793] и отправил данные для поддержки. @latitude: Ты уже создал тикет на support@mikrotik.com и отправил им запрашиваемую информацию? Поскольку ты, как говоришь, сделал тестовую среду с этой проблемой, это должно быть хорошим местом для отладки для команды поддержки MK, как мне кажется.
11.05.2014 20:26:00, DjM.

sstp-туннели отключаются по таймауту

Wed, 05 Mar 2014 10:27:00 -0500

sstp-туннели отключаются по таймауту RouterOS в форуме RouterOS.
Привет, сообщество! У нас происходит странное поведение с sstp-туннелями на версиях V6.7 и V6.10. Локальное устройство — OgmaConnect, удалённые устройства — RB750G.

Начальная ситуация: sstp-сессия не установлена. Теперь мы запускаем sstp-сессии с удалённых устройств A и B. Оба туннеля стабильны. Пока всё хорошо.

После прерывания одного из туннелей он восстанавливается, но начинает постоянно переключаться из-за таймаутов keepalive/inactivity. В то же время другая sstp-сессия остаётся стабильной.

Анализ ошибки показал, что echo-request с локальной стороны (Ogma) не доходит до удалённой и вызывает таймаут. Лог на локальной стороне говорит, что echo-request был отправлен, но, похоже, он «поглощается» самим Ogma. То же самое в обратную сторону — echo-request, отправленный с удалённой стороны, в логе локального устройства отображается как полученный ответ, но ответ не доходит до удалённого устройства.

Пакетный захват показывает, что TLS-пакет с локальной стороны вообще не отправляется. Мы проверили настройки фаервола, но никаких подозрительных моментов не нашли — при первоначальной настройке оба туннеля работают стабильно, обмен echo-request/response идёт без проблем.

Проблема воспроизводится, если есть две и более sstp-сессии, и начинается после того, как первый туннель прерывается и восстанавливается.

Кто-то сталкивался с таким? Любая помощь приветствуется, включая советы по дальнейшему локальному анализу проблемы.
05.03.2014 10:27:00, latitude.