Le ecureuil

Принято, посмотрим.

nginx не падал, он просто не стартовал в не-роутер режиме из-за неправильного конфига. Уже все поправлено.

В таком режиме да, причем не только версию IKE (только IKEv1), но и общий PSK для всех из них, и общий IKE proposal, и нужно использовать ID сторон в виде IP-адресов (ограничение протокола IKEv1). В таком случае все реально.

Если ноды 1 и 2 будут только VIP-серверами, а соединения для туннелей будут устанавливать ноды 1 и 2 в клиентском режиме к нодам 3-4-5 (они будут серверами), то тогда все отлично.

Попробуйте еще отключить аппаратный модуль для IPsec: > crypto engine software

Собирайте голоса, возможно в opkg-kmod-netfilter добавим модули ядра из xtables-addons. Но это будет только версия 1.42, ветка 2.x нам не подойдет.

В свежих сборках много изменений по части стабильности, попробуйте их.

У вас на сервере (Giga) судя по всему бардак с default route. Сами смотрите. Extra все делает правильно, предпринимая попытки открыть IKE SA с Giga, это видно как в ее логе, так и в логе Giga (видим в логе Giga начиная с Jan 20 23:47:20 постоянные получаемые от Extra пакеты и отправляемые ей ответы, которые уходят не в GigabitEthernet0/Vlan2, а неизвестно куда, потому что Extra их не получает обратно). А то, что у вас запасным default route становится USB-модем хорошо видно вот здесь: Jan 20 23:38:44 ndm: Dhcp::Client: adding a default route via 192.168.0.1. После чего сразу отваливается PPTP по таймауту и IPsec. Возможно стоит создать отдельную тему по поводу маршрутизации и приоритетов на default route, но сперва проверьте как вообще все это работает, в какой интерфейс реально идут пакеты и что при этом наблюдается в Web и логах.

ping с устройства в Интернет всегда проходит? Если да, то выставите MSS для crypto map вашего Virtual IP сервера поменьше: >crypto map <servername> set-tcpmss 1200

Конфигурации с set-peer на обоих сторонах не спасут ситуацию, вам нужно чтобы сервер цеплялся к вам (тогда фактически он будет клиентом множества туннелей), но это возможно только если есть прямая видимость удаленных узлов.

Попробуйте.

@alekssmak @avanti-sysadmin Все изменения, сязанные со стабильностью и надежностью IPsec обязательно будут перенесены в 2.08. Однако просьба по возможности проверить, исправлены ли ваши проблемы на 2.09, чтобы убедиться, что все хорошо. Иначе придется ждать до следующего выпуска 2.08.

В наших тестах на 7621 можно получить не более 20 Мбит/с А результаты как у товарища по ссылке можно получить лишь на OpenVPN/TCP, что в целом не рекомендуется для массового применения.

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

Нет. Порт не меняется, можно поменять только community и пару описательных параметров навроде location.

Только сервер, на клиентах все равно багифксов нет, а там тоже довольно много изменений (надеюсь в лучшую сторону :)).

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

Web валидирует прошивку и подпись, поэтому он не даст вам засунуть испорченную, а также просто неправильный файл. Можете попробовать.

Если вы имеете в виду запись в conntrack, то после удаления следующий же пакет создаст ее вновь. Вам точно это нужно?

https://www.dropbox.com/s/u8sr29qoc2i60cq/20170120_1104_Firmware-Keenetic_Giga_II-v2.09[AAFS.1]A1.bin?dl=0

Только giga2. Сейчас вам в личку ссылку пришлю.

Сразу всех предупреждаю. Получение данных по SNMP довольно сильно нагружает систему. Поэтому выставление SNMP в Internet на порту по умолчанию с community public черевато тем, что боты могут нагрузить ваш роутер так, что он встанет колом.

Не хотелось бы на неделю затягивать еще + скоро выйдет стабильная версия 2.08, и чем больше туда багфиксов войдет, тем всем же лучше.

Если затем попробовать прошить через Web, он принимает оба файла без ошибок?

А с провайдером можно договориться, чтобы он и IPTV, и PPPoE к MAC WAN роутера привязал, или это малореально?