Routing from one network to another via the Wireguard > OpenVPN chain?

Question

openvpn

Good afternoon.
There are 4 networks and a zoo of devices (in fact, only 2 networks and a couple of devices in them are of interest).

192.168.11.0 is my personal network, 192.168.12.0 is my friend's, 192.168.1.0 and *.2.0 are company networks.
Here's the diagram:


I can ping the entire 192.168 network from my phone. 11.0 and 192.168. 12.0 .
From 192.168.11.3 I can ping EVERYTHING around.
I'm interested in a way to make it possible to ping all networks from under 192.168 networks. 11.0 and 192.168. 12.0 and, most importantly, the ability to ping from a phone on the 192.168 network. 1.0 and 192.168. 2.0(that is, so that the packets are first passed through WG, and then through OpenVPN). And it is critically important that the network is 192.168. 1.0 and 192.168. 2.0 packages from 192.168. 11.0 and 192.168. 12.0 came from under IP 192.168.2.90 (all foreign traffic is blocked in the company's networks).

On 192.168.2.90, only one ruled iptables:

iptables -t nat -A POSTROUTING -s 10.8.2.0/24 -o ens32 -j SNAT --to-source 192.168.2.90

and all other employees who use this tunnel can easily access *.1.0 and *.2.0 networks without any problems.

On 192.168.11.3, as I understand it, you don’t need to register anything in iptables, since it just acts as a client? This is what I don't understand

What is all this for? In order to have access to the home network, to the friend's network and to the company's networks (the same *.1.0 and *.2.0) from the phone and computers at home without actually using any additional software on the end devices, except for the phone, on which, thanks to this scheme, you will need to use only ONE vpn with ONE connection for everything (and personal), which will work automatically and always in the background. You won't have to bother with a bunch of OpenVPN certificates, but just use the only one (already received at work) on one computer 192.168.11.3 (HP microserver with debian 10) and then dance "on that track".

Answer 1

When we go from the server itself 192.168.11.3 to 192.168.1.* and 192.168.2.*, then the IP of the local end of the tunnel is set as the outgoing address, in this case 10.8.2.3, so everything works. This is easy to check with a command like:
ip route get 192.168.1.77
When such traffic comes from the phone, it has an IP address of 10.1.3.2. With this address, traffic gets to astrave-mainsrv and is subsequently routed to openvpn or not allowed to pass to astrave-mainsrv (depending on how it is configured there). Similar garbage happens with traffic from networks 192.168.11.* and 192.168.12.* - it will not go into the tunnel with the source address 10.8.2.3.
Solution: on astrave-mainsrv, all traffic going to openvpn should be NATed to 10.8.2.3.
Like this (here tun666 is the openvpn interface):
iptables -t nat -A POSTROUTING -s 10.1.3.0/24 -o tun666 -j SNAT --to 10.8.2.3
Or even like this (then you don't have to worry about which IP is on our side of the tunnel, especially if it's dynamic):
iptables -t nat -A POSTROUTING -s 10.1.3.0/24 -o tun666 -j
MASQUERADE will get to astrave-mainsrv):
iptables -t nat -A POSTROUTING -o tun666 -j MASQUERADE
General sense: if a company wants to see all the traffic of an employee connecting via VPN from address 10.8.2.3, then we must send all traffic from this addresses, replacing the source address.