Как пробросить трафик из под сети VPN на RouterOS?

Question

[Alex Devera]

Доброго времени суток.
Господа знатоки, подскажите где затык.
Вводные:
Имеется домашняя сеть - 192.168.31.0/24
Имеется l2TP IPsec сервер на тике. При подключении к нему, с внешки, клиенту выдаётся адрес 192.168.1.2 из пула 192.168.1.0/24
Требуется простое действие что бы клиент(ы) мог ходить на ресурсы в подсеть 31.0 . Раньше решение было элегантным хоть и костыльным. Было простое правило в firewall которое разрешало ходить из одной подсети в другую.

action=accept chain=input dst-address=192.168.31.0/24 in-interface=all-ppp protocol=tcp src-address=192.168.1.2

Это было на моём hap2 с RouterOS 7.7. Сейчас же сижу на hap3 с RouterOS 7.9.1 и такая фишка уже не помогает. При создании такого правила я могу достучаться только до самого роутера 31.1 Но не дельше.
Даже если брать всю подсеть VPN соединения (src-address=192.168.1.0/24) не помогает. Тыкните меня носом пожалуйста что делаю не так. Заранее спасибо.
ЗЫ: Клиент получает внешний ip роутера и спокойно через него ходит в инет.

конфиг огнестены и ната

/ip firewall filter
add action=add-src-to-address-list address-list="BlackList (ssh)" address-list-timeout=4w3d23h59m59s chain=input dst-port=\
    22 in-interface=ether1 protocol=tcp
add action=add-src-to-address-list address-list="BlackList (winbox)" address-list-timeout=4w3d23h59m59s chain=input \
    dst-port=8291 in-interface=ether1 protocol=tcp
add action=add-src-to-address-list address-list="BlackList (RDP)" address-list-timeout=4w3d23h59m59s chain=input dst-port=\
    3389 in-interface=ether1 protocol=tcp
add action=add-src-to-address-list address-list="BlackList (Telnet)" address-list-timeout=4w3d23h59m59s chain=input \
    dst-port=23 in-interface=ether1 protocol=tcp
add action=accept chain=input comment=ICMP protocol=icmp
add action=accept chain=input dst-port=80,443 in-interface=ether1 protocol=tcp
add action=accept chain=input dst-port=13231 protocol=udp
add action=accept chain=input comment="L2TP " dst-port=500,1701,4500 in-interface=ether1 protocol=udp
add action=accept chain=input dst-address=192.168.31.0/24 in-interface=all-ppp protocol=tcp src-address=192.168.1.1
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=forward out-interface-list=WAN
add action=accept chain=forward disabled=yes ipsec-policy=out,ipsec
add action=drop chain=input connection-state=invalid
add action=drop chain=forward connection-state=invalid
add action=drop chain=output log-prefix=dns-flood out-interface-list=WAN protocol=udp src-port=53
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new
add action=drop chain=input in-interface-list=!LAN

/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN
add action=dst-nat chain=dstnat comment=Site dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.31.24 to-ports=80
add action=dst-nat chain=dstnat comment=Site dst-port=443 in-interface-list=WAN protocol=tcp to-addresses=192.168.31.24 to-ports=443
add action=dst-nat chain=dstnat comment=MC dst-port=25565 in-interface-list=WAN protocol=tcp to-addresses=192.168.31.35 to-ports=25565
add action=dst-nat chain=dstnat comment="PZ server IN" dst-port=16261 in-interface-list=WAN protocol=udp to-addresses=192.168.31.27 to-ports=16261
add action=dst-nat chain=dstnat comment="PZ server OUT" dst-port=16262 in-interface-list=WAN protocol=udp to-addresses=192.168.31.27 to-ports=16262

Comments

[Valentin Barbolin]

192.168.1.0/24 и 192.168.0.0/24- самые неудачные сети который можно было выбрать для VPN. Эти пул пересекаются в 90% случаев с домашней сетью SOHO роутера.

src-address=192.168.1.2
судя по этому правила на VPS включен или был включен NAT для VPN интерфейса, и когда клиент из сети 192.168.1.0/24 сучиться в сеть 192.168.31.0/24, то VPS маскирует его под 192.168.1.2.

[Alex Devera]

Valentin Barbolin, домашняя - 31.0 да 1.0\24 выбрана для примера. Её изменение не повлияет на результат. :(

[Valentin Barbolin]

Alex Devera, В чем смысл скрывать внутреннюю VPN сеть ? )

Если пинг доходит до 192.168.31.1, а дальше не идет, то скорее всего нет обратного маршрута.

Имеется домашняя сеть - 192.168.31.0/24

Микротик gateway в этой сети?

Тут сложно что-то сказать, показывай весь конфиг микротика, в частности
/ip firewall export
/ip route export

[Alex Devera]

Valentin Barbolin, route пустой. Не считая затушенного WG.
И уточню никакого VPS нету :) Клиент - это обычный телефон. Я просто делаю доступ для себя "к себе".

[Valentin Barbolin]

Alex Devera,

Имеется l2TP IPsec сервер на тике.

тике - это микротике, понятно.

Так WG или LT2P ?

[Alex Devera]

Valentin Barbolin,
На WG можно не обращать внимания. Он 1) Не настроен. 2) С ним проблем не возникнет.
Сейчас затык именно в l2TP. Он не может стучаться дальше самого роутера.
Если угодно - вот

route правила.

/ip route
add disabled=no dst-address=192.168.31.0/24 gateway=10.7.0.1 routing-table=main suppress-hw-offload=no

[Valentin Barbolin]

Alex Devera,

/ip route
add disabled=no dst-address=192.168.31.0/24 gateway=10.7.0.1 routing-table=main suppress-hw-offload=no

Что это?

Сейчас затык именно в l2TP. Он не может стучаться дальше самого роутера.

Какие маршруты у клиента после поднятия туннеля?

[Alex Devera]

Ответ нашёлся. (тут помогли) Косяк в правиле. В предпоследнем правиле небыло настроено устовие дропа именно с WAN порта. А дропалось все входящие, в том числе и из "доверенных зон".

Answer 1

[Alex Devera]

Ошибка в предпоследнем правиле фильтрации трафика.

spoiler

add action=drop chain=forward connection-nat-state=!dstnat connection-state=new
должно быть
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

Отсутствует интерфейс на котором делать drop, поэтому дропались абсолютно все соединения.
Подсказали тут