Le ecureuil

Напишите лучше отзыв на google play, это однозначно дойдет до непосредственных разработчиков, причем быстрее и надежнее

ebtables есть в Entware или в Debian.

Нет никакого глобального заговора "модности и молодежности". Ответ-то проще, надо только подумать и посмотреть по сторонам. Я отвечаю за ipsec и туннели и присутствую на этом форуме, потому лично мне это важно и интересно, потому об этом здесь много обсуждения и вообще движухи. Вон представители команды dect тоже тут есть, и активны, и у них в темах постоянная движуха тоже есть. Те же, кто делают шейперы, intelliqos, igmp, фильтрации, мобильное приложение, wifi и прочее - их на форуме нет (ну или почти нет, @Padavan например появляется раз в неделю), он им неинтересен от слова "вообще". Они работают по ТЗ и обратной связи из других источников, хотя медленно, но верно ваши хотелки туда тоже передаются (естественно в устной форме "для сведения"). Потому никто и не реагирует на ваши темы.

Средствами NDMS невозможно, однако через Opkg есть возможность взять ebtables в свои руки и подкрутить - модули ядра для него лежат в пакете opkg-kmod-netfilter.

В данной теме multiwan - это маршрут по умолчанию на несколько интерфейсов, о другом тут вроде и не говорят.

Что значит "держать self-test"? Вам же нужно только скачать файл через пару минут после отвала, и все. Что вы там держать собрались?

Прикладывайте сюда ваш конфиг openswan, чтобы не быть голословным, а также пояснение откуда и куда идет трафик.

А где self-test после разрыва и неудачных попыток реконнекта? Мы же не телепаты.

Это проприетарные расширения juniper, которые мы не поддерживаем. И ospf у нас тоже нет от слова вообще.

Какие именно Lite III: просто или rev. B? Где self-test с роутеров во время отвала клиентов?

Судя по приложенному логу - у вас реально или подвисает модем, или проблемы с сотовой сетью. Роутер при пропадании связи честно перезагружает модем, и все восстанавливается. Со стороны Keenetic криминала не видно.

Пойдет любая от 1 гига, берите самую скоростную и выносливую из всех, что найдете - иначе или будет тупить заметно, или со временем умрет (может даже без вскриков).

По идее должны, если они есть в vanilla 3.4

Сейчас изоляция доступна только между раздельными сегментами (или bridge, или интерфейс vlan). Внутри сегмента настроить изоляцию между клиентами невозможно.

А теперь предлагаю всем, кто люто голосует за Multiwan "искаропки" описать, как же обычному человеку объяснить все эти глюки, что наблюдает @Leonid Goltsblat (и они очень логичны, и скорее всего в той или иной степени будут проявляться при Multiwan у всех). Плюс рассмотрите вариант с Multiwan, когда у человека будет WAN1 - IPoE, WAN2 - PPPoE DSL с серым адресом, WAN3 - USB свисток с двойным NAT. На самом деле это основное ограничение для интеграции Multiwan в прошивку (а костылять с привязкой популярных сервисов к одному интерфейсу мы не хотим, это скорее на бред похоже, чем на качественное универсальное решение).

Нет идей. Может быть все, что угодно. Это случается чаще под нагрузкой, или и в простое с такой же частотой?

По политике, для подробностей гуглите устройство XFRM.

Для IPsec не нужны маршруты и настройка в firewall, также он не создает какого-либо особого интерфейса VPN.

У вас винда? Если да, то она по-умолчанию блокирует прием пакетов с источником не из своей подсети. А IPsec не делает NAT, в итоге сохраняется оригинальная адресация. Попробуйте настроить firewall на клиентах.

Эти роутеры являются маршрутизаторами в своих сетях? gateway на клиентах прописан через них?

Чем вам создание еще одного сегмента в web не подходит?

Если на одной из crypto map включен virtual ip и она в пассивном режиме, то все остальные crypto map будут отключены (потому что они так и так не будут работать и рано или поздно выплывут конфликты). Это не касается l2tp/ipsec и автотуннелей в клиентском режиме. В теории потом можно будет добавить "расслабляющую" проверку, и если параметры IKE совпадают, то включать эти crypto map все равно - тогда конфликта не будет. Возможно к следующему релизу сделаю, но пока этого нет.

Вы только учтите, что эти датчики вообще не калиброваны и метрологически не поверены. Потому они показывают не градусы цельсия, а свои собственные единицы (которые, возможно, иногда совпадают с *C, а иногда вообще нет), которые использутся прошивкой для компенсации мощности и ухода частоты WiFi (а этому алгоритму метрологическая сертификация вобщем-то побоку). Потому говорить о "температурных датчиках" в отношении этих устройств обратной связи немного некорректно.

А хоть немного подробнее, с примерами? Я вот ничего не понял.

Шифрование PPTP не ускоряется нигде, ни в сервере, ни в клиенте.