Le ecureuil

Не планируется.

Попробуйте на vpn-сервере увеличить интервал lcp эхо через 
> vpn-server lcp echo 180 6
> system configuration save

Благодаря @r13 найдена причина, будет исправлено в выпуске 3.6.A12.

Второй - он из Policy0. Но там видимо запросов нет, потому и нулевые значения.
Запускается по одному серверу DNS для каждой политики, потому их может быть много.

В 3310/3410 случайно оказался отключен в сборке. В следующих релизах все будет.

В версии 3.7 появился Keenetic SDK.

В 3.6.B.0 должно стать лучше.

@Leksey118 прошу прощения за столь долгий ответ - был занят.
Вообще, настройки очень странные - аж на трех интерфейсах одинаковые DNS-сервера...
Но нашел небольшой баг, который приводил к неработоспособности в proxy - в следующем выпуске должно быть поправлено.

Реализовано в 3.5 Alpha 16

Причина найдена, должно быть поправлено в следующих сборках.

Явно настроить совсем разные DNS для разных политик пока невозможно. Можно только указать, какие будут использованы в той или иной из общих.

Будет поправлено в следующих релизах.

Поправлено.

Поправлено, появится в следующей сборке.

На публичной точке доступа ежедневная проходимость может быть и до десятка тысяч уникальных хостов в гостевом сегменте в день.
Предлагаете для всех них хранить информацию и тратить процессор?

Нашли хитрый и закопанный баг, починено. В следующих сборках будет поправлено.

Всем спасибо, найдено и починено.
Если кратко, то причина была в росте размера структуры tcp_skb_cb, которая начала конфликтовать с флагами ppe software, из-за чего когда байт в skb->cb[46] становился равен 0x4 происходил отброс пакетов.
Вообще нужно отметить странную политику расположения полей с tcp_skb_cb в ядре 4.9. Если поменять поля в union tx : оба skb_mstamp поставить в начале (они требуют выравнивания по 8), а u32 в конце, то структура будет занимать не 48, а 44 байта. И такой проблемы никогда бы ни было. Ну да ладно. И проявляется это кстати везде, а не только на 7621 - но на нем локальный трафик заметнее и чаще используем.
Хочется сердечно поблагодарить всех за упорные репорты этой проблемы - без них мы бы не поняли реальную важность, и сочли бы ее возможным аппаратным багом или глюками ПО на клиентах - что, на нашей практике, бывает все же чаще.
Но отдельная благодарность объявляется господину @KorDen за настойчивость, исследование и выделение минимального сетапа для воспроизведения ситуации. Также он был первым, кто обратил внимание на связь jiffies с потерями (мы и сами до самого конца не верили, что дело в этом) и выявил конкретный диапазон. И его догадка в итоге привела нас к разрешению ситуации. Еще раз хочется отметить, что это был не просто наброс в стиле "не работает, быстро чините, б...дь" или "после обновления не стоит, жена ушла к другому, сын гей"; а технически выверенный репорт с указанием как воспроизводить (и даже скриптом).
За этот образцовый багрепорт @KorDen отблагодарим самым новым и крутым устройством, которое появится уже скоро.
Еще раз всем спасибо.

Короче сделали команду
> no ip http easy-access
оно уже доступно в 3.01 beta, и отключает bind на :80 если порт сменен.

Спасибо за подсветку проблемы.
Сейчас этот функционал на самом деле работает, но провайдеры перехватывают нешифрованные dns и тупо их блокируют (в том числе и запросы в зону .lib).
Потому нашел вам кучку opennic-серверов, которые умеют dot и doh.
Добавляйте их к обычным dot/doh серверам, и все будет работать:
https://servers.opennic.org/edit.php?srv=ns10.de.dns.opennic.glue
https://servers.opennic.org/edit.php?srv=ns12.nh.nl.dns.opennic.glue
https://servers.opennic.org/edit.php?srv=ns8.he.de.dns.opennic.glue
https://servers.opennic.org/edit.php?srv=ns31.de.dns.opennic.glue
 
Прямо сейчас не поддерживаются DoH-сервера с указанием порта в uri, но в следующих релизах это будет поправлено.

Да, ситуация воспроизвелась, но, формально говоря, это не ошибка - это следствие работы фильтра.
При включенных интернет-фильтрах у нас включается блокировка транзитного DoH и DoT - чтобы никто не смог убежать наружу сквозь фильтры.
При этом adguard проверяет себя через https-запрос на 443 порт на свои же домены и сервера, используемые для DNS - а мы этот транзит блокируем, потому что считаем его "попыткой пробежать мимо".
Вот он и не показывает сам себя.
Потому призываю всех не беспокоиться, все работает как заявлено, и даже еще жестче в плане блокировки утечек 

Начиная с 2.15 выдается wildcard-сертификат, который покрывает все домены 4 уровня автоматически.

В итоге под пристальным взором нашли источник проблемы.
Порт действительно блокируется на вход, и сессии все уничтожаются - тут вопросов нет.
Однако web-сервер в таком случае не закрывает соединение, и пытается доотправить данные клиенту (или просто происходит TCP retransmit, что не суть важно).
При этом побочно создается новая _исходящая_ сессия к браузеру, через который он все-таки умудряется пролезать и продолжать работать - из-за HTTP Keepalive сессии у браузера тоже завершаются не мгновенно.
Поскольку сессия получается "исходящей", она не блокируется по условию и не очищается.
Всем спасибо за репорты, в следующих релизах будет исправлено.
 
Прямо сейчас это неактуально для ботов, потому что большинство из них закрывают TCP-сессию при отлупе, а это обрывает соединение.

Реализовано только в 3.1.

На 2.0-5 должно быть все нормально.

Если вы включите Интернет-фильтр, то все запросы "мимо", включая даже dot/doh мимо - будет завернуты на роутер или дропнуты. Такая штука существует для plaintext udp/53 и tcp/53 еще с 2.06, а для dot/doh появилась в 3.0.
Что еще осталось, кроме black-list?
Запуск скриптов по cron считаю избыточным, потому что в системе без opkg это излишество (скрипты хранить негде), а с opkg вы так и так можете поставить cron.