Le ecureuil
-
Постов
11 067 -
Зарегистрирован
-
Посещение
-
Победитель дней
648
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
Попробуйте-ка отключить 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 / Межсетевой экран Для туннелей нет ограничения.
-
Исправлено, будет в следующей сборке.
-
Ага, затесалась еще одна мелочевка. Поправлено, будет как обычно в сегодняшней сборке.
-
Спасибо за репорт, исправлено. Войдет в ближайший релиз.
-
Нет, IP-адрес или FQDN сервера (он должен быть глобальным, или это должен быть проброшенные порты 500/4500 UDP на этом адресе до сервера). Локальный адрес вычислится автоматом на основе роутинга, так что tunnel source тут лишний. Плюс IPsec сам создаст все настройки для прохода сквозь NAT до реального адреса сервера, ему не нужно в этом помогать.
-
@enpa, @r13 - туннели на базе EoIP/IPsec и GRE/IPsec концептуально несовместимы с PPTP-подключениями из-за того, что PPTP тоже использует протокол GRE. У вас есть всего лишь один вариант - использовать IPIP/IPsec. Занесу инфу в шапку.
-
Реакция на команды interface up/down поправлена, войдет в ближайший релиз.
-
Реализовано, появится в ближайшем релизе.
