Le ecureuil

Ваша проблема на самом деле очень сложна для реализации в виде, чтобы и настраивать было легко, и работало нормально. Однако у нас сейчас находится в активной разработке компонент dpi, который поможет решить эту проблему. SIP ALG тут вообще не при чем, он работает только на транзитном трафике в случае NAT, позволяет правильно проходить вспомогательным протоколам навроде SRTP.

Вообще поддержка Keenetic первого поколения завершена на версии 2.04, и новых релизов не планируется. Но специально для вас собрана неофициальная 2.04 с поддержкой opkg: http://files.keenopt.ru/firmware/Keenetic/2016-05-21/ Нужно лишь немного поискать

Четыре простые команды > system set net.ipv4.netfilter.ip_conntrack_fastnat 0 > no ppe software > no ppe hardware > system configuration save

Будем чинить, а до починки продаваться не будет.

Ответ на оба вопроса: нет.

Первая проблема уже передана разработчикам веб-интерфейса, они разбираются. По поводу второй - приложите self-test.

Переделано взаимодействие IPsec-подсистемы с подсистемой туннелей (касается и L2TP/IPsec, до пятничного релиза не успели) из-за ее несоответствия новым реалиям, должно помочь. Однако у вас я вижу, что клиент сообщает о невалидном ключе. Проверьте еще раз preshared-key на клиенте и сервере - одинаковы ли они? Если да, то попробуйте убрать ipsec encryption-level strong.

В 2.06 никаких серьезных изменений по функционалу вноситься не будет, только исправление ошибок и уязвимостей.

Судя по всему, у вас модем в режиме HiLink внутри себя рвет PPP-соединение с провайдером, и присылает на роутер ICMP network unreachable для всех исходящих наружу пакетов. Явной вины роутера не видно. Можно попробовать использовать другие модемы (например, в режиме RAS) или другого провайдера мобильного интернета, или поиграть с расположением модема так, чтобы уровень сигнала был достаточным и соединение не разрывалось.

Все устройства за Lite II снаружи для Ultra II видны с MAC-адресом Lite II из-за особенностей режима работы "Адаптер", потому в данном случае шейпер не работает и зарегистрированные устройства показываются странно.

Вы можете использовать 2.08 из draft, технически обновление уже есть. Официального же релиза не планируется.

В Keenetic только режим клиента, сервера L2TP/IPsec нет.

L2TP/IPsec конфигурируется там же, где и все клиентские туннели PPPoE/PPTP/L2TP еще со времен draft 2.06, а для GRE/IPIP/EoIP пока не придуманы типовые пользовательские сценарии, и соответственно пока не будет морды.

Дошел, разбираемся.

Переезжаем в соответствующий раздел.

Закрываем тему как исправленную и переносим в соответствующий раздел.

С MTU это нормальное поведение, потому что мы никак не можем узнать MTU удаленного хоста, только MTU своего исходящего интерфейса. Если у вас столь разные условия и вы наблюдаете проблемы с доступностью, можете жестко задать MTU на обоих концах через > interface IPIP0 ip mtu <value> где value - минимальное значение из двух. Насчет расписаний - туннели это очень новая фича, пока обкатываем ее в cli (вон сколько недочетов за две недели вылезло), чтобы ей пока пользовались только те, кто может вменяемо описать проблему . Веб про нее соответственно ничего не знает, посмотрим со временем.

Поправлено (причем скорее всего обе проблемы), появится в новом релизе.

Исправлено, теперь при каждой попытке реконнекта заново происходит разрешение удаленного endpoint.

Выкладывайте self-test, без него слишком много ненужных вопросов.

Попробуйте привязать access-list к интерфейсу, скорее всего в этом причина неработоспособности. В вашем случае это будут такие команды: > interface ISP ip access-group LIST_TEST_D in или же > interface Home ip access-group LIST_TEST_D out То есть сперва определяете интерфейс, через который придет трафик (ISP или Home), затем направление трафика (in или out), и затем сообразно этому задаете источник и назначение. Должно работать.

Попробуйте-ка отключить ppe: > no ppe software > system configuration-save

Скорее всего именно ваш Android-телефон по каким-то своим внутренним причинам не хочет отправлять WoL-пакеты на широковещательный адрес, потому что если работает ARP и вообще IP-протокол поверх WiFi, значит широковещательные адреса для WiFi-клиентов доступны и работают нормально.

Если вы так уверены, то может покажете где именно там ошибка? А вообще - отключение всех ppe (hardware, software) вам помогает? Почему же вы тогда не оставите их выключенными?

Правильно, потому что если хотите через конкретный интерфейс, нужно указать > interface PPPoE0 connect via ISP Это все есть в CLI-мануале.