Le ecureuil

Первая проблема уже передана разработчикам веб-интерфейса, они разбираются. По поводу второй - приложите 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-мануале.

Он никак не добавляется. crypto map match-address, если вы прочтете в мануале по CLI, нужен для задания сетей в IPsec SA Traffic Selectors, и больше ни для чего, ни для каких фильтраций он не используется! А для фильтрации нужно просто создать access-list, заполнить его, и все.

Please provide self-test from page System -> Files as hidden post and several examples of websites you experience problems with.

Конкретно по ссылке был баг с Big-Endian CPU, который касался появления поддержки новой платформы. На всех остальных Little-Endian устройствах это не сказывалось. Ну и да, работает ppe только в направлениях WAN <> LAN, на передачу LAN <> LAN он не влияет.

Есть какие-либо подкрепления фактами утверждения о том, что ppe software "режет скорость" на WiFi?

Да, нужен еще один. Этот access-list используется только для настройки, и из него читается только самое первое правило.