r13

Ну по идее того что написано достаточно(сервер, логин, пароль, общий ключ) ну раз не завелось ну и ладно.

Надо смотреть трафик, вдруг он работает, но весь трафик через 10.8.0.2 гуляет

@Saymer Можете еще L2TP/IPSec попробовать.

Гениально! маршруты появились Правда ip шлюза не верный Подставился клиентский ip @Le ecureuil Конструкция в конфиге сервера почему то легла с клиентским ip в качестве шлюза в таблицу маршрутов.: route 192.168.4.0 255.255.255.0 route 192.168.2.0 255.255.255.0 селф далее

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

пинги идут в обе стороны, если у вас не идут, то проверьте правила firewall, разрешили ли вы доступ на соответствующем интерфейсе.

Нету в redmi note 4x ac

так как раз смысл ccd в том что сервер считывает от туда конфиг актуальный для конкретного клиента в частности iroute указывает что данная подсеть за эти клиентом, и ее пушить не надо. PS что читает видно в логе: Sep 12 21:25:22OpenVPN1 r13_ios/192.168.1.104 OPTIONS IMPORT: reading client specific options from: /storage/ccd/r13_ios

вести с полей! ccd в storage работает, iroute подхватился. Ковыряю передачу маршрутов host`у @ICMP зачем вы /storage/cdd/client2.txt создали с расширение txt? создайте без расширения.

В перечисленных мной временных интервалах в время первое это rekey инициированный клиентом(23:32), 2е rekey инициированный сервером через час после соединения 23:43(rekey interval 3600) Или я что то не допонял?

Да, и обратный маршрут тоже нужен, если OpenVPN с той стороны не является default route

Счетчик rekey interval

@Le ecureuil Почему при rekey приходящем с удаленной стороны не сбрасывается счетчик на кинетике? Примеры в селфе 23:32 - 23:43 и 01:42 - 1:54 И еще вопрос, зачем IPSec/L2TP клиент участвует в выборе IPSec на совместимость? Я думал это относится только к "серверам"?

@ICMP c ccd пока подружиться не удалось, но ipp вполне себе в файлик на флешке адреса скидывает Так что по идее ipp и статическая маршрутизация на роутере должны работать если на сервере нет директивы client-to-client

Раз пошла такая пьянка покручу сегодня папку ccd и по результатам скину сюда структуру.

Это не есть best practice ибо выдежка из документации: Note that the entries in this file are treated by OpenVPN as suggestions only, based on past associations between a common name and IP address. They do not guarantee that the given common name will always receive the given IP address. If you want guaranteed assignment, use --ifconfig-push

Это также реализуемо через ccd а не отдельным файлом, смотрите ниже документацию по вашей же ссылке

подозреваю что те которые содержатся в client-config-dir

@Le ecureuil Feature Request на будущее: привязка ip адресов к клиентам, по аналогии с pptp сервером. UPD: А, все нашел(работает), уже есть оказывается. спасибо.

нет необходимости в opkg например.

По идее пока если только создавать ccd на внешней флешке. Надо пробовать

Ну так как это сервер то private :)

@Le ecureuil У меня на Ultra2 на 2.11 с включенным прошивочным OpenVPN сервером обнаружил сегодня такое веселье в home.hosts: Выводит всю подсеть сервера. ЗЫ на 2.10 такого не замечал. ЗЫ2 Я так понимаю надо для него отключить опрос ip hotspot? Вечером скину селфтест.

2all Iphone не сбрасывает l2tp ipsec туннель при уходе в сон в отличие от подключения посредством virtual-ip, так что есть весомый плюс для перехода на этот тип подключения

@Le ecureuil Start2 2.11.A.1.0-0 + ios 10.3.3 Периодически при соединении подобный лог: я так понимаю l2tp запускается раньше поднятия ipsec и получается ошибка: Sep 10 19:53:07accel-ppp l2tp: new tunnel 30972-9 created following reception of SCCRQ from 192.168.1.34:60470 Sep 10 19:53:07accel-ppp l2tp tunnel 30972-9 (192.168.1.34:60470): impossible to process the send queue: sending packet 0 failed Sep 10 19:53:07accel-ppp l2tp tunnel 30972-9 (192.168.1.34:60470): impossible to send SCCRP: transmitting messages from send queue failed Далее l2tp пересоздается и все корректно работает: Sep 10 19:53:08accel-ppp l2tp: new tunnel 33212-9 created following reception of SCCRQ from 192.168.1.34:60470 Sep 10 19:53:08accel-ppp l2tp tunnel 33212-9 (192.168.1.34:60470): established at 192.168.1.104:1701 Sep 10 19:53:08accel-ppp l2tp tunnel 33212-9 (192.168.1.34:60470): new session 43382-8065 created following reception of ICRQ селф далее.