r13

А остальные настройки которые через 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. Понятно что настройка кривовата но надо бы подкрутить обработку исключения.

потестил с no connect, все отлично работает

Положу свежий селфтест с 2.10.A.6.0-0

Ок, попробую с connect / no connect Кстати, галка в веб интерфейсе в настройках PPTP делает up/down или connect / no connect?

@Le ecureuil Протестировал маршрут до узла, с авто туннелями все четко. (тестировал с и без маршрутом добавленным вручную 2 параллельных туннеля к 1й точке IPIP и PPTP) А вот PPTP наоборот после отключения пересоздает маршрут. В логе следующее: Так же при запуске роутера даже отключенный PPTP создает маршрут:

Конфиг через веб, но доработать напильником через cli

@Le ecureuil Маршрут добавляется, спасибо. Буду тестить. Тем временем новая хотелка: Сейчас туннели over ipsec считаются поднятыми всегда независимо от реального состояния. Из-за этого при использовании туннеля в качестве маршрута по умолчанию при падении канала не происходит ухода на резерв. Так же после перезагрузки возникает ситуация что интернет не доступен так как поднимается туннельный интерфейс с максимальным приоритетом но не может поднять соединение так как так как идет попытка получить tunnel destination через себя же(в случае если нет днс прописанного жестко через определенный работающий интерфейс). Хотелось бы получить сходное поведение с PPTP соединениями и им подобными и для автоматических туннелей over ipsec PS как я понимаю подобное было сделано для OpenVPN соединений в крайнем драфте

1 Думаю ставьте, хуже не будет, и не бойтесь экспериментировать, я также как и вы занимаюсь экспериментами 2 зависит от вашей специфики, есть ли резервный канал, какието доугие каналы через которые надо или не надо устанавливать туннель в самом простом случае можете выбрать ваше основное интернет подключение

тогда смотрите логи, в чем проблема, должно работать.

@ICMP 1)Просто прописываете ddns имя вместо ip в настройке 2) nat надо прописать на сервере в cli(имя интерфейса подставьте свое): interface OpenVPN1 security-level private ip nat OpenVPN1 system configuration save

Просто warning что сервер использует не стойкое шифрование.

Удалить cert блок по идее исходя из текста ошибки.

Выкладывать селфтесты для разработчиков если есть подозрение на баг

Еще в самом начале @Le ecureuil писал что серверная часть тоже есть, так что встроенная, иначе сюда бы не писал

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

Если у вас все роутеры одинаковые, и есть те на которых установлена нужная версия с нужным набором компонентов, то сливаете с нее прошивку (Закладка Система-Файлы далее firmware) И таким же образом устанавливаете эту прошивку на реципиентов

Спасибо, так используется настроенное в конфиге шифрование.

@Le ecureuil Запустил OpenVPN в режиме сервера, конфиг следующий: При подключении клиента почему-то используется шифрование AES-256-GCM вместо настроенного AES-256-CBC? PS В клиентском режиме все ок Лог с клиента

На драфте и попробуем эти сценарии

Необходимости добавлять default route это не отменит, но это однократная операция, так что не проблема. А вот маршрут до сервера позволит избежать потери удаленного клиента без возможности удаленной корректировки в случае изменения ip сервера.

На клиенте, так как он выполняет соединение. При соединении добавлять маршрут до ip узла определенного при резолве tunnel destination Через интерфейс определенный при резолве tunnel source ip адреса.(если на клиенте указан конкретный интерфейс tunnel source то все просто, если auto то думаю тоже возможно) Таким образом получится использовать туннель как маршрут по умолчанию и в том числе для динамического ip сервера.

Все(IPIP, EoIP, GRE), без ipsec подложки. Если нужно через нат, то запускать туннель через ipsec.