r13

Как уже писал до этого @Le ecureuil работа vpn туннелей со стороны лан не проверяется и по сему ее корректность не гарантируется.

Тогда подождем ответа разработчиков. Тем временем если охота поковырять как сейчас работает и убедиться что мои предполажения верны, можно поснимать трафик дергая ddns по http, чтобы посмотреть какой url отправляется брокеру.

Такс значит при такой конфигурации переменная ${ip} не актуализируется что по моему мнению не верно @ndm @Le ecureuil может все таки скорректируем несколько логику dyndns? Чтобы если в url испОльзуется подстановка ${ip} она бы возвращала актуальный ip не зависимо от настроки send-address Сейчас получается нельзя передать custom url с подстановкой ip, но без прибавления хвоста к url со стороны ndms. Это я думаю будет безболезненно изменить. Если же говрить о концепции custom url в целом то ndms в любом случае не должен ничего добавлять к url предлагая только api из скажем ${ip} ${ip6} ${domain} ${user} и ${password} которые заполняются из остальных настроек dyndns а пользователь уже из них формирует требующийся url. Но это уже достаточно основательный редизайн, так что рассмотрите пожалуйста первое предложение. Он по идее должно быть безболезнненым с точки зрения обратной совместимости, а над вторым можно будет подумать кода будете добавлять поддержку ipv6 в ddns. custom url 2 ? Ps @Leksey118 ваш сервис варианта с автоопределением адреса не имеет?

Попробуйте явно задать no send-address

@Leksey118 В настройках должен быть настроен custom url и стоять галка определять ip автоматически, все остальное пустое, у вас так настроено?

Если на клиенте есть firewall то это вполне может быть. обратное действие - пинг сервера с клиента работает?

На клиенте firewall открыт для этого соединения?!

А дальше как с любым другим vpn, заходите на него по ip. Важно чтобы маршруты были настроены на клиенте, и на сервере если нужно (текущий клиент маршруты не запрашивает, появится в следующей сборке)

Чойта мне кажется @ndm поторопился, на 2.12.A.3.0-1 нету dhcpinform с встроенным SSTP клиентом. Кстати это фикс клиента или сервера(На старых версиях клиенты PPTP, L2TP/IPSec запрашивают маршруты?)

а если подключиться виндовым клиентом то есть dhcpinform на сервере. значит ndm клиент не запрашивает принудительный ввод ip dhcp client routes не помог, но судя по документации и не должен помочь, так как по умолчанию включено.

нет, в логе его нет ни с какой стороны

так интерфейс поправил, теперь ок, что нужно чтобы клиент запросил маршруты? зы клиента в вебе настраивал

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

@Le ecureuil и еще, не смотря на настройку на сервере sstp-server dhcp route 192.168.1.0 255.255.255.0 маршрут на клиенте не подхватился. не работает пока? upd прописал маршрут на клиенте, заработал трафик с сервера, с клинта пока нет, видимо на сервере тоже с firewall ом тоже надо шаманить и еще, кажись правила iptables замножаются upd2 Да, судя по вот этой цепочке пакеты только на внешний адрес принимаютя?! если идти с клиента на внешний адрес сервера то пакеты проходят.

выложил кстати, трафик у меня по этому туннелю пока не ходит...только эхо ходит судя по логу

А сертификат на это имя получен?

Так: За остальным в базу знаний

готово

@Le ecureuil и еще Если соединяемся через облако remote endpoint определяется облачный, но затем remote IP address определяется как внешний адрес сервера это так и задумано? Не понятно. [I] Feb 1 22:48:27 ndm: Network::Interface::PppTunnel: "SSTP0": remote endpoint is resolved to "91.218.112.172". [I] Feb 1 22:48:27 ndm: Core::ConfigurationSaver: saving configuration... [I] Feb 1 22:48:27 ndm: Network::Interface::PppTunnel: "SSTP0": local endpoint is resolved to "192.168.0.168" (via "CdcEthernet0"). [I] Feb 1 22:48:27 ndm: Network::Interface::PppTunnel: "SSTP0": added host route to 91.218.112.172 via 192.168.0.1 (CdcEthernet0). [I] Feb 1 22:48:28 ndm: Network::Interface::Ppp: "SSTP0": enabled connection via any interface. [I] Feb 1 22:48:30 pppd[3472]: Plugin sstp-pppd-plugin.so loaded. [I] Feb 1 22:48:30 pppd[3472]: pppd 2.4.4-4 started by root, uid 0 [I] Feb 1 22:48:30 pppd[3472]: Using interface ppp0 [I] Feb 1 22:48:30 pppd[3472]: Connect: ppp0 <--> /dev/pts/0 [I] Feb 1 22:48:31 pppd[3472]: CHAP authentication succeeded [I] Feb 1 22:48:31 pppd[3472]: local IP address 172.16.3.10 [I] Feb 1 22:48:31 pppd[3472]: remote IP address 178.140.123.132 [I] Feb 1 22:48:31 pppd[3472]: primary DNS address 178.140.123.132 [I] Feb 1 22:48:31 ndm: Core::ConfigurationSaver: configuration saved. [I] Feb 1 22:48:31 ndm: Network::Interface::Base: "SSTP0": interface is up. [I] Feb 1 22:48:31 ndm: Network::Interface::Base: "SSTP0": interface is up. [I] Feb 1 22:48:31 ndm: Network::Interface::Ppp: "SSTP0": adding nameserver 178.140.123.132. [I] Feb 1 22:48:31 ndm: Dns::Manager: name server 178.140.123.132 added, domain (default). [I] Feb 1 22:48:31 ndm: Network::Interface::IP: "SSTP0": IP address is 172.16.3.10/32.

@Le ecureuil Сделал клиент сервер, все практически по умолчанию На клиенте выставляется DNS равный внешнему ip сервера. Странновато... [I] Feb 1 22:36:04 ndm: Network::Interface::Base: "SSTP0": interface is up. [I] Feb 1 22:36:04 ndm: Network::Interface::Ppp: "SSTP0": disabled connection. [I] Feb 1 22:36:04 ndm: Network::Interface::PppTunnel: "SSTP0": remote endpoint is resolved to "178.140.123.132". [I] Feb 1 22:36:04 ndm: Network::Interface::PppTunnel: "SSTP0": local endpoint is resolved to "192.168.0.168" (via "CdcEthernet0"). [I] Feb 1 22:36:04 ndm: Network::Interface::PppTunnel: "SSTP0": added host route to 178.140.123.132 via 192.168.0.1 (CdcEthernet0). [I] Feb 1 22:36:04 ndm: Network::Interface::Ppp: "SSTP0": enabled connection via any interface. [I] Feb 1 22:36:06 pppd[2875]: Plugin sstp-pppd-plugin.so loaded. [I] Feb 1 22:36:06 pppd[2875]: pppd 2.4.4-4 started by root, uid 0 [I] Feb 1 22:36:06 pppd[2875]: Using interface ppp0 [I] Feb 1 22:36:06 pppd[2875]: Connect: ppp0 <--> /dev/pts/0 [I] Feb 1 22:36:07 pppd[2875]: CHAP authentication succeeded [I] Feb 1 22:36:07 pppd[2875]: local IP address 172.16.3.10 [I] Feb 1 22:36:07 pppd[2875]: remote IP address 178.140.123.132 [I] Feb 1 22:36:07 pppd[2875]: primary DNS address 178.140.123.132 [I] Feb 1 22:36:07 ndm: Network::Interface::Base: "SSTP0": interface is up. [I] Feb 1 22:36:07 ndm: Network::Interface::Base: "SSTP0": interface is up. [I] Feb 1 22:36:07 ndm: Network::Interface::Ppp: "SSTP0": adding nameserver 178.140.123.132. [I] Feb 1 22:36:07 ndm: Dns::Manager: name server 178.140.123.132 added, domain (default). [I] Feb 1 22:36:07 ndm: Network::Interface::IP: "SSTP0": IP address is 172.16.3.10/32.

@eralde @Dmitry Tishkin Привет, на экране Другие подключения замените состояние у подключений на тумблеры как на других вкладках: Ну и до кучи сделайте тоже самое для проброса портов пожалуйста

Видимо смотреть в сторону 2.11 и https://forum.keenetic.net/topic/3450-netflow

Нет, это же баг приложения, сегодня вышло обновление для ios - v43

@Alex Sh. Добрый день, в новой версии на ios добавляю расписание. если далее в этом расписании ткнуть на No devices в группе Devices то приложение закрывается.

На новой версии (проверил на ios) пофиксено.