Le ecureuil

Переезжаем в соответствующий раздел.

Закрываем тему как исправленную и переносим в соответствующий раздел.

С MTU это нормальное поведение, потому что мы никак не можем узнать MTU удаленного хоста, только MTU своего исходящего интерфейса. Если у вас столь разные условия и вы наблюдаете проблемы с доступностью, можете жестко задать MTU на обоих концах через > interface IPIP0 ip mtu <value> где value - минимальное значение из двух. Насчет расписаний - туннели это очень новая фича, пока обкатываем ее в cli (вон сколько недочетов за две недели вылезло), чтобы ей пока пользовались только те, кто может вменяемо описать проблему . Веб про нее соответственно ничего не знает, посмотрим со временем.

Поправлено (причем скорее всего обе проблемы), появится в новом релизе.

Исправлено, теперь при каждой попытке реконнекта заново происходит разрешение удаленного endpoint.

Выкладывайте self-test, без него слишком много ненужных вопросов.

Попробуйте привязать access-list к интерфейсу, скорее всего в этом причина неработоспособности. В вашем случае это будут такие команды: > interface ISP ip access-group LIST_TEST_D in или же > interface Home ip access-group LIST_TEST_D out То есть сперва определяете интерфейс, через который придет трафик (ISP или Home), затем направление трафика (in или out), и затем сообразно этому задаете источник и назначение. Должно работать.

Попробуйте-ка отключить ppe: > no ppe software > system configuration-save

Скорее всего именно ваш Android-телефон по каким-то своим внутренним причинам не хочет отправлять WoL-пакеты на широковещательный адрес, потому что если работает ARP и вообще IP-протокол поверх WiFi, значит широковещательные адреса для WiFi-клиентов доступны и работают нормально.

Если вы так уверены, то может покажете где именно там ошибка? А вообще - отключение всех ppe (hardware, software) вам помогает? Почему же вы тогда не оставите их выключенными?

Правильно, потому что если хотите через конкретный интерфейс, нужно указать > interface PPPoE0 connect via ISP Это все есть в CLI-мануале.

Он никак не добавляется. crypto map match-address, если вы прочтете в мануале по CLI, нужен для задания сетей в IPsec SA Traffic Selectors, и больше ни для чего, ни для каких фильтраций он не используется! А для фильтрации нужно просто создать access-list, заполнить его, и все.

Please provide self-test from page System -> Files as hidden post and several examples of websites you experience problems with.

Конкретно по ссылке был баг с Big-Endian CPU, который касался появления поддержки новой платформы. На всех остальных Little-Endian устройствах это не сказывалось. Ну и да, работает ppe только в направлениях WAN <> LAN, на передачу LAN <> LAN он не влияет.

Есть какие-либо подкрепления фактами утверждения о том, что ppe software "режет скорость" на WiFi?

Да, нужен еще один. Этот access-list используется только для настройки, и из него читается только самое первое правило.

Ну и для всех - агрессивный режим небезопасен, если вы можете повлиять на настройки juniper, лучше настройте main mode.

Нет.

По идее при каждом падении соединения должен, если не так, то это надо поправить.

Для входящих IPsec-соединений это реально только в случае, если будут выбраны одинаковые IKE proposals, одинаковый PSK и разные IKE ID. В противном случае клиенты будут пытаться лезть в чужую crypto map. Это врожденная особенность работы протокола IKE.

Да, все верно, наконец-то эта проблема была решена. Осталась мелочь навроде автоопределения MTU для IPsec, это будет в релизе через неделю. На днях обновим мануалы.

И это тоже пока нельзя.

Нет, все еще нельзя.

В части случаев после сброса настроек и загрузки с конфигом по умолчанию не поднимались точки доступа (2,4 или 5, или обе вместе). Теперь это исправлено.

ACL / Межсетевой экран Для туннелей нет ограничения.