r13

В режиме over ipsec клиент серверная модель. Со стороны сервера в настройке есть только tunnel source a со стороны клиента только tunnel destination. А не как у вас обе настройки с обеих сторон. Так настраивается голый туннель без ipsec транспорта.

@pdn_mail Лучше конечно пакеты поснимать и посмотреть что там гуляет, А так на вскидку можно попробовать включить nat на кинетике для туннеля: ip nat Gre0

Какое-то время назад в свежих версиях лимит подняли до 64х насколько я помню.

В обоих случаях один из интерфейсов создает этот host route Вопрос про различие в выборе sorce интерфейса: IPIP похоже выбирает тот что является default route(и поэтому соединение идет через PPTP), а PPTP тот что определил из таблицы роутинга а именно ISP из этой записи host route. Или не так?

@Le ecureuil А сейчас возможно реализовать роутинг в клиентские сети? То что реализуется через настройку client-config-dir и файлики клиентов с iroute?

@Le ecureuil Ставлю экспериент: Основное соединение ISP Если Поверх него в качестве интернет соединения поднят PPTP то последующий IPIP интерфейс поднимается через PPTP0. Если же поверх ISP в качестве интернет соединения поднят IPIP то последующее поднятие PPTP интерфейсa поднимается через ISP. PPTP настроен как подключаться через любое интернет подключение. Почему такие различия в поведении? селфтест далее.

Ну тк это уже не 2 сети, а одна сеть. маска здесь определяющий фактор.

Калькулятор ip адресов подскажет

Вполне получится.

Странно это, а воспроизводимость проблемы с откатом к предыдущей прошивке поверяли? Если воспроизводится, то выдавайте селфтесты @Le ecureuil для анализа.

А в чем по вашему будут отличия от текущей реализации? Конфиги все равно вам подготавливать.

Не, это не ко мне. Я OpenVPN исключительно в академических целя гоняю. Так что ресурсов по его настройке не ведаю. Все гугол + ручками конфиги.

@ICMP Я конечно не специалист, но возможно из-за этой настройки: remote-cert-tls server Выдержка из конфига: # To use this feature, you will need to generate # your server certificates with the nsCertType # field set to "server". The build-key-server # script in the easy-rsa folder will do this. #ns-cert-type server #remote-cert-tls server ЗЫ а зачем такой хитрый dns? push "dhcp-option DNS 127.0.0.1"

С голыми тоже все автоматом, у меня такой Eoip трудится без каких бы то ни было настроек в firewall

Не, для поднятия самого туннеля ничего открывать не надо, и так работает. Надо открывать для пакетов внутри туннеля при настройке public.

У вас будет единый сегмент с 2 серверами, если это никак не разграничивать, то клиенты будут рандомно получать ip от любого из доступных серверов.

Да, сначала ipsec, потом бриж. ЗЫ А потом решение граблей с dhcp если с обоих сторон работают dhcp сервера

Да спасет. но нужно выполнить команду no isolate-private для public все как у всех: все входящие соединения по умолчанию закрыты. настройки как для любого другого интерфейса, на вкладке межсетефого экрана.

У вас security-level public на итерфейсах Отсюда вопрос: firewall настраивали для пропуска пакетов по туннелю?

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

Показывайте все настройки если расчитываете на помощь не только от @Le ecureuil И если используете туннель без ipsec, то с обоих концов должны быть белые ip.

У вас как то странно все, интерфейс создаете IPIP0, а в бридж включаете EoIP0. Проверьте еще раз конфиги.

А остальные настройки которые через cli делаются сделали? Они описаны в теме с журналом изменений.

Подкрутить в плане выводить без "system failed" A без указания tunnel source на клиенте в случае еще одного туннеля в тот же destination не получается, Иначе в моем случае IPIP нуннель идет через роут через ISP при этом резолвя source oт PPTP0 интерфейса. IPIP туннель при этом не поднимается. В случае же указатия и source и destanation все заводится. Но это частный случай. в общем случае да, достаточно указать только destination на клиенте. Фактически указание tunnel source на клиенте это аналог настройки "Подключаться через" у других соединений.

@Le ecureuil Смоделировал ситуацию "криворучки", когда PPTP интерфейс уже создал свой роут через ISP а у IPIP интерфейса указан source PPTP а не ISP в этом случае: Aug 21 21:12:02ndm Network::Interface::Tunnel: "IPIP4": resolved destination 77.23.136.81 (*.mykeenetic.net). Aug 21 21:12:02ndm Network::Interface::Tunnel: "IPIP4": resolved source 192.168.5.204. Aug 21 21:12:03ndm Network::Interface::Tunnel: "IPIP4": system failed [0xcffd0464], unable to get route to tunnel destination endpoint. Понятно что настройка кривовата но надо бы подкрутить обработку исключения.