ale_xb

Заработало. Дело оказалось, действительно в файрволе роутера. После команды no isolate-private доступ к хостам за vpn сервером из моей LAN появился. Мне это не совсем понятно, т.к. в справочнике CLI Keenetic написано, что всем создаваемым новым интерфейсам присваивается public security-level, а трафик из private (Home LAN) в public (tun1) разрешен по умолчанию. Возможно, здесь что-то работает не совсем так, т.к. интерфейс tun1 создан не средствами CLI, а вовсе доп.пакетом из entware и по команде show interface он (tun1) никак не отображается. Попробовал отключить nat-ирование, т.е. убрать правило маскарадинга, все работает и без него. Странно, мои проверки в предыдущем посте показывали его необходимость. Впрочем, tcpdump на интерфейсе tun1 показал, что icmp request уходят с src=ip tun1, т.е. nat-ирование все же работает и без моего доп.правила. В справочнике CLI keenetic нашел команду ip nat vpn которая включает/выключает nat-ирование для vpn клиентов. Во-первых, не ясно, работает ли эта команда для любых vpn-клиентов или только, встроенных в прошивку или для части из них, во-вторых, не указано ее значение по умолчанию, но, похоже, что "включено". Вот так выглядит цепочка POSTROUTING в таблице nat. Проверил, команда no ip nat vpn удаляет из этой цепочки последнее 4-е правило, но доступ из моей LAN к хостам за vpn-сервером сохраняется и в этом случае: # iptables -t nat -nL POSTROUTING --line-numbers Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 _NDM_IPSEC_POSTROUTING_NAT all -- 0.0.0.0/0 0.0.0.0/0 2 _NDM_SNAT all -- 0.0.0.0/0 0.0.0.0/0 3 _NDM_MASQ all -- 0.0.0.0/0 0.0.0.0/0 4 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 ndmmark match 0x40/0x40 Я не силен в netfilter/iptables, и несколько десятков цепочек/правил в Keenetic понять (пока) не могу, но все равно придется разбираться, как теперь это (файервол) правильно настроить при поднятом туннеле opennconnect, чтобы не попортить настройки безопасности на роутере. Ну и стартовый скрипт для openconnect добавить, конечно.

Продолжу пока разговор самим с собой. Пробовал ловить трафик на интерфейсах tcpdump-ом. Обнаружил, что пинги с самого роутера ходят до хостов за vpn сервером нормально только с src=ip на tun1. Если попытаться указать src=ip другого интерфейса роутера, например, смотрящим внутрь LAN, echo request уходит с интерфейса tun1 в сторону vpn сервера нормально, но останется без ответа. Если же сначала добавить правило nat-ирования (моё сообщение выше), echo reply начинает приходить нормально и для этого src. Напрашиваются выводы: 1) nat-ирование нужно, т.к. vpn сервер дропает все, что пришло с "неправильного" интерфейса, т.е. src!=ip tun1; 2) при пингах хостов за vpn-сервером с любого хоста из моей LAN видно, что echo request нормально приходит на интерфейс br0, но на tun1 этот запрос не появляется. Вероятно, он дропается файерволом роутера. Надо разбираться с этим и/или, возможно, как уже писал выше с interface security-level . Позже попробую это подкрутить.

Вот тоже, очень интересует эта тема. Ставлю openconnect, туннель до Cisco ASA поднимается, маршруты на keenetic прилетают и даже в отличие от автора темы хосты за ASA отвечают на пинги. Но вот дальше - та же беда, все это не доступно из локалки. Есть подозрение, что NAT для tun1, который поднимается с помощью openconnect не работает. Пробовал руками добавить правило iptables -t nat -I POSTROUTING -d 172.27.96.0/24 -s 192.168.100.0/24 -o tun1 -j MASQUERADE не помогает. Счетчик пакетов для данного правила, так и остается нулевым. Может, что-то еще с interface security-level на keenetic следует подкрутить?