r13

скорее всего со стороны клиента работает файвол который блокирует входящие пакеты из сети роутера.надо с эти разбираться. маршрут нормальный.

@Le ecureuil Не, не помогло та же картина(пересоздал тоннели без strong encription, проверил одинаковость PSK сравнив значения running-config). Господа, у кого нибудь на последней прошивке IPIP over IPSec поднимается?

Курить это https://zyxel.ru/kb/4214/ в части маршрутов и сетевого экрана

@Le ecureuil Что-то на v2.08(AAUX.1)A11 у меня савсем IPIP over IPSec подниматься отказывается (IPSec туннель не поднимается) Сервер Ultra, клиент Ultra2 Уже несколько раз туннели пересоздавал, не заводится. селфтесты с обоих ниже.

Еще бага: На гиге 2 создан IPIP туннель в режиме клиента. находится в состоянии down. В конфиге состояние сохранено После перезагрузки IPSec все равно пытается создать туннель не смотря на состояние down. Если через cli выполнить interface IPIP0 down то попытки создать IPSec туннель прекращаются но постоянно пересоздаются iptables таблицы в цикле (срабатывает netfilter хук) селфтест далее.

В вебе, вкладка Сегменты, если для гостевой

Команда трассировке работает за счет формирования пакетов с нарастающим ttl А подобная доработка меняет ломает ее работу, поэтому при фиксации ttl все заканчивается сразу за модемом, шлюзы при этом остаются те же самые.

@Padavan Даже с этой незначительной частью есть явные улучшения, ultra первая уже 2 дня аптайма с поднятым ipsec туннелем.(ранее и часа не держалась) Спасибо.

Нет, так как это только увеличение ttl а не фиксация. Если за роутером зоопарк из разнородных устройств с разным исходным ttl то и на выходе будет разный. ЗЫ проверить что работает на модеме просто: Запустить трассировку любого узла в интернете. Если следующий узел после модема сразу конечный то значит изменение ttl в модеме работает.

Места в роутере не хватит. В некоторых моделях одна то прошивка с более менее большим набором компонентов не входит.

Вылезла еще одна бяка с ресолвером ip туннеля. В текущей реализации насколько я понимаю если ресолвинг удался то полученный ip запоминается, и по нему происходит попытка соединения Если подключение идет через USB модем и соединение с интернет еще не установлено, то такие модемы резолвят все на себя и IPSec начинает долбится в модем Как часто происходит повторный ресолвинг адреса endpoint туннеля?

Еще вопрос поднятый @KorDen по соединению home-ipip пока добавил в iptables правило iptables -A FORWARD -o ipip0 -j ACCEPT Соединение работает. Через штатный ACL такое можно реализовать? Или оставить это в opkg?

Спрошу тут так эта новая фича, Как подружить IPSec туннеля и IPSec Virtual IP? У меня они могут пытаться лезть не в свою критокарту и ничего хорошего при этом не происходит. Как происходит выбор криптокарты при входящем соединении? Селфтест с примером далее.

Не поделитесь как проще смотреть куда реально идут пакеты?

@Le ecureuil Если на момент запуска не возможно отресолвить dns имя endpoint туннеля (доступ в интернет еще не поднялся после перезагрузки) то туннель IPSec больше не поднимается. down/ up на интерфейсе не помогает, помогает пересоздание endpoint адреса селфтест ниже.

@Le ecureuil В дальнейшем планируете реализовать для клиент серверного режима указывать не конкретный интерфейс а использовать интерфейс текущего подключения к Интернет? что-то вроде tunnel source default что бы работало в том числе в схеме с резервированием интернета

@Le ecureuil Пока удалось поднять GRE over IPsec и IPIP over IPsec но чисто номинально, по логам все ок поднялось, но трафик не ходит. Попутно вылезла несовместимость GRE туннеля и штатного PPTP клиента: создал туннель, клиент отвалился и покругу пытается безуспешно подключиться. Грохнул туннель и клиент сразу же подключился. селф тест в следующем посте. UPD пинги из под ентвари до удаленного роутера работают, а пинги с компьютера не идут, не понятно....

@enpa В Cli прописать то что расписано в инструкции от @Le ecureuil по этим новым подключениям Например для IPIP После этого в системе появится новый интерфейс IPIP0 И для него можно прописывать маршруты в web интерфейсе точно также как и для PPTP подключения.

@Le ecureuil И вдогонку, если остановить этот интерфейс, (сделать Interface IPIP0 down) то связанный с ним IPSec продолжает попытки подключиться. UPD Я так понимаю нужно сделать Interface IPIP0 no connect чтоб перестало коннектиться?

@Le ecureuil Попытался поднять IPIP over IPSec между 1й и 2й ультрами Лог с ошибкой: Nov 08 22:30:12ndm IpSec::Configurator: reconnecting crypto map "IPIP0". Nov 08 22:30:14ndm IpSec::Configurator: start shutting down crypto map "IPIP0" task. Nov 08 22:30:14ipsec 12[CFG] received stroke: unroute 'IPIP0' Nov 08 22:30:14ipsec 05[CFG] received stroke: terminate 'IPIP0{*}' Nov 08 22:30:14ipsec 05[CFG] no CHILD_SA named 'IPIP0' found Nov 08 22:30:14ipsec 14[CFG] received stroke: terminate 'IPIP0[*]' Nov 08 22:30:14ipsec 14[CFG] no IKE_SA named 'IPIP0' found Nov 08 22:30:14ndm IpSec::Configurator: shutting down crypto map "IPIP0" task done. Nov 08 22:30:15ndm IpSec::Configurator: start initiating crypto map "IPIP0" task. Nov 08 22:30:15ipsec 15[CFG] received stroke: initiate 'IPIP0' Nov 08 22:30:15ndm IpSec::Configurator: initiating crypto map "IPIP0" task done. Nov 08 22:30:15ipsec 09[IKE] sending XAuth vendor ID Nov 08 22:30:15ipsec 09[IKE] sending DPD vendor ID Nov 08 22:30:15ipsec 09[IKE] sending Cisco Unity vendor ID Nov 08 22:30:15ipsec 09[IKE] sending NAT-T (RFC 3947) vendor ID Nov 08 22:30:15ipsec 09[IKE] sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID Nov 08 22:30:15ipsec 09[IKE] initiating Main Mode IKE_SA IPIP0[63] to 176.14.124.109 Nov 08 22:30:15ipsec 11[IKE] received DPD vendor ID Nov 08 22:30:15ipsec 11[IKE] received NAT-T (RFC 3947) vendor ID Nov 08 22:30:15ipsec 11[CFG] received proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# Nov 08 22:30:15ipsec 11[CFG] configured proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/# Nov 08 22:30:15ipsec 11[CFG] selected proposal: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# Nov 08 22:30:16upnp sendto(udp_notify=7, 192.168.1.1): No such device Nov 08 22:30:16upnp Core::Syslog: last message repeated 10 times. Nov 08 22:30:17ipsec 06[IKE] received INVALID_KE_PAYLOAD error notify Nov 08 22:30:17ndm IpSec::Configurator: remote peer of crypto map "IPIP0" returned invalid key notification. Nov 08 22:30:17ndm IpSec::Configurator: fallback peer is not defined for crypto map "IPIP0", retry. Nov 08 22:30:17ndm IpSec::Configurator: schedule reconnect for crypto map "IPIP0". Nov 08 22:30:17ndm Network::Interface::SecureIPTunnel: "IPIP0": IPsec layer is down, shutdown tunnel layer. Nov 08 22:30:17ndm Network::Interface::SecureIPTunnel: "IPIP0": secured tunnel is down.

Ну этот момент в задаче не раскрыт, так что исходим из широкого трактования постановки задачи

Это не AP Isolation раз в задаче "разрешить пару портов" стоит.

Для понимания "аккуратнее" надо знать какие маркировки уже заняты IPsec и для ppe software чтоб не пересечься, посему хотелось бы услышать связанные ограничения поподробнее.

@Дмитрий А скрипт в винде случайно не редактировали?

Удалять не обязательно, достаточно лишить прав на доступ на вкладке Система-Пользователи