How to reach a machine in a VLAN behind an OpenVPN server?

Question

openvpn

The ESXI hypervisor has a VM-router that acts as a NAT and OVPN server, has two interfaces: eth0 (ip 46.4.120.218, looks to the Internet) and eth1 (VLAN).
There are many virtual machines in the VLAN that have local addresses like 192.168.182.*/28 and access the Internet through NAT.
Using OVPN, I try to connect to any of these local virtual machines in the VLAN, but the ping from the OpenVPN client does not pass to any ip 192.168.182.*/28:

PING 192.168.182.17 (192.168.182.17) 56(84) bytes of data.

I set up OpenVPN according to the official doc (without affecting TLS while I understand the basics).
As a result, I see a new tun0 interface with ip 10.9.8.1 on the VPNServer virtual machine, and tun0 with ip 10.9.8.2 on the VPNClient. After running OpenVPN on both machines, communication goes fine, pinging on ip 10.9.8.* goes great.
IPv4 forwaring on OpenVPN server is enabled.
OpenVPN server routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         46.4.120.193    0.0.0.0         UG    0      0        0 eth0
10.9.8.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
46.4.120.192    0.0.0.0         255.255.255.224 U     0      0        0 eth0
192.168.182.16  0.0.0.0         255.255.255.240 U     0      0        0 eth1

OpenVPN client routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         88.198.179.46   0.0.0.0         UG    0      0        0 eth0
10.9.8.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
88.198.179.40   0.0.0.0         255.255.255.248 U     0      0        0 eth0

Iptables config on OVPN Server:

# NAT для VLAN
*nat
-A POSTROUTING -s 192.168.0.0/16 -o eth0 -j SNAT --to-source 46.4.120.218
COMMIT

# Проброс портов
*filter
-A FORWARD -s 192.168.182.0/24 -d 88.198.179.41/29 -j ACCEPT
-A FORWARD -d 192.168.182.0/24 -s 88.198.179.41/29 -j ACCEPT
COMMIT

Config tun0 on OVPN Server:

dev tun0
ifconfig 10.9.8.1 10.9.8.2
secret /etc/openvpn/static.key

Config tun0 on OVPN Client:

remote 46.4.120.218
dev tun0
ifconfig 10.9.8.2 10.9.8.1
secret /etc/openvpn/static.key

Maybe the problem is that the VPN Client doesn't know where to forward the 192.168.182.* packets? Maybe you need to add some route?
PS openvpn config:

port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key 
dh dh1024.pem

# ip отличается от tun0, это ок?
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "route 192.168.182.0 255.255.255.240"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Answer 1

To access the local network, you need to enable traffic forwarding between interfaces in the system core on the OpenVPN server:
And enable forward on the firewall:

iptables -A FORWARD -s 192.168.182.0/24 -d 10.250.4.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.182.0/24 -s 10.250.4.0/24 -j ACCEPT

Answer 2

change the tun interface to tap. part of the config

cat server.conf
port 1194
proto tcp
dev tap
.......

Answer 3

IMHO:
- It's better to use tun - this way you get more flexible access to the subnet(s) from the client.
- Change the default port to something else.
- Start using TLS encryption as soon as possible. Everything is simple there.
dev tun
local х.х.х.х - external ip on which we listen
port хххх - port on which we listen from the external interface
proto udp
server 192.168.168.0 255.255.255.0 - virtual subnet where clients work with
push server "route 192.168.0.0 255.255.255.0" - real grids behind the server
push "route 192.168.1.0 255.255.255.0"
route 192.168.168.0 255.255.255.252
client-config-dir ccd - automatic entry of the route to the client.
client-to-client - to access clients directly. [ This and the previous options are the answer to your question ]
comp-lzo - traffic compression parameter
keepalive 10 120
tun-mtu 1500
mssfix 1450 - restriction of packets sent from clients (only when using udp)
verb 3 - for informative logs.
============
dev tun
remote х.х.х.х xххх is the external ip of the server and our non-standard port.
proto udp
comp lzo
tun-mtu 1450
mssfix
verb 3
=======
We start, look at the logs.
No more shamanism. On the firewall, the port we are using must be available.
UPD: I don’t know how it is with penguins, but demons don’t need to configure anything else (no fireworks or routing by left commands) / Inspired by the first answer and comments to it /

Answer 4

Yes, the problem is that the client does not have a route to the 192.168.182.0/28 network, why he did not receive it can be seen in the log (most likely the client was launched without sudo). You can add it yourself for a while:
It is better not to touch the configuration of the client and server yet, everything is satisfactory in it.
This is the first, and secondly, I don’t know what is specified as gateway on machines behind eth1, but it’s better to add this entry to iptables:

*nat
...
-A POSTROUTING -s 10.8.0.0/24 -d 192.168.182.0/28 -o eth0 -j MASQUERADE
...
COMMIT