Le ecureuil

А на этих устройствах точно нет firewall? Если IPscanner их видит, то как минимум ARP работает - трафик проходит.

> no ntce upstream rate-limit ISP

Ну вы хоть подробнее объясните, что такое "онлайн светятся", но "друг друга не видят". Это как вообще? Где "светятся"? Если они "светятся", значит какой-то трафик (хотя бы для обнаружения) все-таки доходит?

Начиная с версии 4.1 DynDns сильно переработан и нормально обрабатывает несколько профилей на одном интерфейсе + несколько интерфейсов в одном профиле.

Возможно они находятся в разных сегментах?

Другое решение пока не планируется.

В качестве решения можно перевесить SSL-порт для веба на другой. Явно же удалять эти правила нехорошо, на них есть завязка по логике.

А можете в скрытом посте прислать har-файлы в ситуации, когда не работает логин?

Нет. Лучше сообщите поподробнее о багах, чтобы они были исправлены.

А что "не исправлено" в этих правилах iptables?

Звучит разумно, сделаем.

LACP требует перехода на DSA, это явно пока не в планах. И в целом я не вижу никакого смысла от LACP кроме активного мониторинга.

Судя по логу, он вполне себе опознался как AsixEthernet0.

Сколько была скорость до, и сколько после?

Со сжатием не работает, нужно его выключить явно.

Пришлите лог с включенным interface debug.

PPTP NAT helper.

Если не работает тоже из-за NAT, то вам только pptp-nat-helper на вашем сервере может помочь.

Пришлите self-test в момент, когда воткнут 20265, но не определился.

security-level у этого интерфейса IPIP какой?

1. Все "глюки, что берется неправильный proposal" - это на самом деле из-за принципиального устройства IKEv1. Если нет строгой необходимости, то использовать его сейчас не стоит примерно никогда в первую очередь из-за подобных вопросов. Также возникающие в логе NO_PROPOSAL_CHOSEN очень похожи на проблемы выбора proposal в IKEv1. 2. Судя по логу, у вас в 13.53 отлично срабатывает DPD и все реконнектится. Проблем визуально не видно. Nov 29 13:53:59 ipsec: 13[JOB]DPD check timed out, enforcing DPD action Nov 29 13:53:59 ndm:ipsec::Configurator: ""office.msk-co1"": remote peer is down." Nov 29 13:53:59 ndm:ipsec::CryptoMapInfo: ""office.msk-co1"": crypto map active IKE SA: 0, active CHILD SA: 0, down." Nov 29 13:53:59 ndm:ipsec::Configurator: ""office.msk-co1"": fallback peer is not defined, retry." Nov 29 13:53:59 ndm:ipsec::Configurator: ""office.msk-co1"": schedule reconnect." Nov 29 13:53:59 ndm:ipsec::CryptoMapInfo: ""office.msk-co1"": crypto map active IKE SA: 0, active CHILD SA: 0." Nov 29 13:53:59 ndm:ipsec::CryptoMapInfo: ""office.msk-co1"": crypto map active IKE SA: 0, active CHILD SA: 0." Nov 29 13:53:59 ipsec: 13[IKE]restarting CHILD_SA office.msk-co1 Еще раз настою, что в случае с несколькими туннелями при любой возможности стоит переходить на IKEv2 и задавать идентификаторы в виде текстовых строк (хотя бы email / fqdn), и не использовать IP-адреса для этой цели.

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

Устройство с 2x2,5 это Challenger/Challenger SE.

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

Да, большое спасибо. Проверьте версию 4.3.а.8, и на ней тоже пришлите self-test.