Access server's lan side form client

sdbr

I've just setup Openvpn server on RPI to connect to my home LAN and it works to some extent.
I can connect to server, internet works also. But I cant ping anything inside my LAN beside RPI itself.
My home LAN is 192.168.1.0/24 , RPI is fixed at 192.168.1.66, and it is behind router (gateway) at 192.168.1.1 (sorry, cant run openvpn on router)
From VPN side, RPI server has address 10.128.7.1 , clients get 10.128.7.0/24
Additional culprit is that client machines have same LAN subnet ie 192.168.1.0/24 as my LAN on other side of VPN.

As suggested in https://community.openvpn.net/openvpn/wiki/HOWTO#IncludingmultiplemachinesontheserversidewhenusingaroutedVPNdevtun I've tried:
- added push "route 192.168.1.0 255.255.255.0" in server config
- enabled ip forwarding on RPI (net.ipv4.ip_forward=1 in sysctl.conf)
- added static back route (on my router) to 10.128.7.0 using 192.168.1.66 (RPI) as gateway

but it doesn't work, can't ping anything in my local LAN (except 192.168.1.66 - Openvpn server). When I switch Openvpn client off, I can ping clients LAN machines successfully.

What should I try next? I'm noob so please consider that.

uweT

You need a Server side (i hope Linux)
iptables -t nat -A POSTROUTING -s 10.128.7.0/24 -d 192.168.1.0/24 -j MASQUERADE
once every server restart
best solution: put it in an autostart file (i use /etc/rclocal)

Now you see the whole Lan behind destination

openvpn_inc

No, absolutely not.

You cannot NAT from one 192.168.1.0/24 to another. Furthermore, why would you want to?

Routing is the proper answer, along with choosing another network address. The steps the OP followed look correct. The problem, of course, was the IP address overlap.

RFC 1918 is huge, big enough for any organization's needs. Spread out and make yourself comfortable therein.

However, please note that the OpenVPN Cloud service does offer IP network overlapping resolution as a feature. This is done via DNS names at the client side, and internal magic in the software to get packets sent where they should go.

regards, rob0