Le ecureuil

Насчет 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-сервере никак.

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

*&%$#|}@$%^&%!!!!!!!!

Нет, не подойдет. Дождитесь сегодняшнего вечера с 2.09 или ставьте официальную 2.08.С на свое устройство (по ссылке фактически она).

Попробуйте вот эту версию: https://www.dropbox.com/s/oircglwii0l4s4n/in_rb_gamma_2.08.C.1.0-0-9-4fcfd7e.bin?dl=0 В текущей 2.09 есть проблемы, которые еще не до конца починили, и одна из них проявляется у вас.

Встроенный iptables не предназначен для использования чем-либо, кроме прошивки. Да, обязательно ставить из пакетов.

Где self-test, снятый после подключения?

Спасибо за интересные наблюдения, примем к сведению.

Эти команды не имеют отношения к policy routing, они лишь фильтр на основе установленных политик XFRM. Что уйдет в 220 можно глянуть в ip rule show ip route show table 220

Почистите кэш браузера, у вас от старого Web остались куски.

Думаю, надо ограничить разрешенную длину PSK до 64, всем хватит.