Le ecureuil

Большое спасибо за репорт, разбираемся.

Как это не используется? А включенный IKEv2-сервер?

Спасибо за репорт, будет поправлено в следующей версии.

Спасибо за репорт, будет поправлено в следующей версии.

А на этих устройствах точно нет 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-адреса для этой цели.