Le ecureuil

Спасибо за репорт, проверим.

Проблема нашлась, она таилась в Web-интерфейсе. Из CLI смена работает как надо. Будем чинить.

Адрес тоже поддерживается. > ip static 192.168.0.0 255.255.252.0 ISP > ip static 192.168.0.0 255.255.252.0 UsbLte0 Единственное важное - чтобы исходящие интерфейсы были public.

О, спасибо! Попробуем найти почему это так, и поправить.

Снимайте дамп Wireshark в случае WS2012 и в случае Keenetic, иначе это гадание на пальцах.

Остается полностью прошлое поведение. Если включен nat - будет с ним, если выключен - будет без него.

Сейчас у нас главное - это обратная совместимость. Да, возможно решение неидеальное и требует особого внимания со стороны настраивающего, но это самое простое что можно было реализовать с сохранением прямой совместимости команд и всех инструкций в базе знаний. ip static out у нас вообще нет ;(

Изменилось все. WPS отключен по-умолчанию, нужно нажать кнопку. Плюс есть проверка на брутфорс, которая сильно замедляет перебор и даже банит устройства при таких действиях. Подробнее у @Padavan

Уже сказали ведь, что проблема не в реализации QoS, а в классификации потоков, и пока основная проблема именно с этим.

Насчет tunnel source auto сделано, насчет недоступности целевого интерфейса продолжаем работу.

Скорее всего проблемы с MTU, скиньте self-test с устройств с обоих сторон туннеля.

IPsec не может быть простым по определению, если он для вас таков - значит уже поработало много людей бессонными ночами У нас же реализация относительно "молодая", возможны несовместимости. Постараюсь проверить ситуацию с Kerio, оставайтесь на связи.

А PSK точно-точно совпадает? Постараюсь проверить, просто никак руки не дойдут до создания стенда с mikrotik.

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

Тоже сделано, см. тут:

Сделано. Можете указывать tunnel source auto, при этом будет использоваться любой доступный WAN (а если WAN нет вообще, то соединение уйдет в standby).

Реализовано. Создаете на интерфейсе профиль ping-check с обязательным указанием restart-interface (без этого не будет переподключения). На мой взгляд лучше всего указать интервал проверки в 30 секунд, а количество попыток - 3. При меньшем интервале при недоступности удаленной стороны у вас весь лог будет завален сообщениями о рестарте туннеля.

Все верно, если этот пакет пришел через IPsec, то он будет "принят" первым правилом, иначе будет отброшен. Это нужно, чтобы роутер не принимал пакеты из незащищенных сетей и не отправлял пакеты в них, если поднят IPsec с определенной удаленной сетью. Плюс из-за особенностей работы XFRM локальная и удаленная подсеть не могут пересекаться. Если вам это нужно - используйте Gre, IPIP или EoIP over IPsec.

Можете тестировать. Отключаете nat на интерфейсе, пакеты с которого не нужно nat-ить (предположим это Home) > no ip nat Home Включаем nat на исходящих интерфейсах, пакеты уходящие в которые нужно nat-ить (предположим это ISP и PPTP0): > ip static Home ISP > ip static Home PPTP0 Все остальные пакеты из Home в другие интерфейсы пойдут без NAT (например, в EoIP0, L2TP0, etc). Чтобы правильно работал ip static исходящие интерфейсы (ISP, PPTP0) обязательно должны иметь security-level public.

@gaaronk @drugold @awoland

@KorDen @IgaX @dexter @avkuzmin

У вас удаленная сторона отвечает "NO_PROPOSAL_CHOSEN", то есть Keentic тут не при чем. Сообщите настройки удаленной стороны, и если вы поднимали сервер сами, тогда еще и версию ПО / железки с той стороны.

Keenetic III нормально подходит, если требования к скорости передачи данных невысокие.

На встроенном ftp-сервере никак.

Ага, благодаря этой теме я кстати уже понял на чем буду тестировать одну фичу