Le ecureuil

На простом Keenetic тоже был включен VPN-сервер: http://files.keenopt.ru/firmware/Keenetic/2016-05-21/ А для IPsec пока еще не все готово, поддержка туннелей поверх IPsec в "нормальном" виде появится только в 2.08, которая еще не вышла в бета/stable версии (но тем не менее, через несколько месяцев выйдет, а пока можете глянуть тут:

Висят в ОЗУ. В NDMS вообще практически ничего не пишется на flash устройства без явной команды пользователя, потому можете быть спокойны.

Нет, он не продавался. Некоторые магазины даже уже добавили его на витрины, но мы остановили процесс отгрузки до решения проблем, и в таком виде пока все и остается.

Нет, просто не добавили из-за других дел наверное В 2.06 уже все, поздно, она вышла в stable и добавления не будет. Однако можем добавить в 2.08, если нужно. Отпишитесь в таком случае.

Ваша проблема на самом деле очень сложна для реализации в виде, чтобы и настраивать было легко, и работало нормально. Однако у нас сейчас находится в активной разработке компонент 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), и затем сообразно этому задаете источник и назначение. Должно работать.