Le ecureuil

Он виртуальный, его нет. Только через ndmq / RCI.

Про conndmmark:

Добавлен патч для conndmmark.

Примерно так.

Покажите лог ядра, на что оно ругается. И еще вывод lsmod.

У вас неправильный пароль где-то. Перепроверьте еще раз. Сегодня весь день проверял комбинации нашего pptp сервера с разными клиентами, включая w7, w10 нескольких последних сборок и кинетиками. Все работало как ожидается.

В логе обрывов нет. Ничего непонятно.

Тут вероятнее всего виноват провайдер.

Отключение аппаратного ускорения и включение фрагментации помогает?

Тогда обратитесь в официальную техподдержку, разжевать или даже помочь настроить - это их работа.

Legacy - это в первую очередь стабильно и надежно, и только потом актуализация

Насчет настроек фаз для автотуннелей - в конце в cli guide есть подробное описание proposal-ов, и то, как их аналоги можно настроить руками.

Стоит попробовать IKEv2 для EoIP, тогда все должно быть совместимо.

У вас порт 8888 на ISP проброшен на устройство в локальной сети? Тогда "закрыть" его не выйдет - проброс порта автоматически и безоговорочно включает доступ на него.

Сброс сессий при добавлении правил не происходит. Потому если сессия жива, то по ней можно продолжать ходить.

Можно настроить свой хост. Установите компонент easyconfig, и в cli появится возможность задавать кастомные хосты для проверки.

Да, знаем, но в низком приоритете.

Такое не планируется, насколько я понимаю.

Пока еще нет. Думаю, сперва стоит обновить transmission до версии 2.94. Кто за?

Версия 2.11.D.0.0-2: удален компонент NortonDNS (сообщил @Sfut) ACME: отключен отзыв сертификата при автоматическом продлении добавлена поддержка модема Huawei E5776 (сообщил @Orbit) IPsec: восстановлена совместимость с сервисом CyberGhost обновлен OpenSSL до версии 1.1.0j обновлен пакет tzdata до версии 2018g WiFi: версии драйверов синхронизированы с 2.14

Обновлены все устройства?

Может SSID-то назовете? У Keenetic стандартный SSID состоит из 4 цифр на конце, это означает, что примерно на каждый тысячный Keenetic SSID будет повторяющимся. Все, больше не вижу смысла толочь воду в ступе.

А, вы проверяли адреса _внутри_ туннеля? Тогда это должно было работать конечно.

Хотелка интересная, однако реализовать ее довольно непросто. Вот представьте - вы подписались на мультикаст, и от вылетает к клиенту в порт свича кинетика. Дальше стоит тупой свитч, не умеющий в снупинг, который рассылает его по всем портам. Теперь если они все включат у себя показ этого потока, это у них заработает, но мы про этот факт даже не узнаем! И что здесь делать? Если кратко - у unicast-трафика источник или назначение ведут к конкретному хосту в сети. А у multicast почти всегда "левый" адрес источника и мультикастный адрес назначения. Как узнать, кто его принимает?

Нужен self-test.