The openvpn win client server does not see the local network behind them. how to fix?

Question

openvpn

Greetings .

win server 2019

Server conf

port 1194
# TCP or UDP server?
;proto tcp
proto udp
;dev tap
dev tun
;dev-node MyTap
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\server.key" # This file should be kept secret
dh "C:\\Program Files\\OpenVPN\\config\\dh.pem"
;topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
;server-bridge
push "route 192.168.1.0 255.255.255.0"
push "route 172.22.24.2 255.255.248.0"
client-config-dir "C:\\Program Files\\OpenVPN\\config\\ccd"
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 8.8.8.8"
;push "dhcp-option DNS 8.8.4.4"
client-to-client
;duplicate-cn
keepalive 10 120
tls-auth "C:\\Program Files\\OpenVPN\\config\\tls-auth.key" 0 # This file is secret
cipher AES-256-CBC
;compress lz4-v2
;push "compress lz4-v2"
#comp-lzo
;max-clients 100
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
;log openvpn.log
;log-append openvpn.log
verb 3
;mute 20
explicit-exit-notify 1

win 10

Client conf

client
;dev tap
dev tun
;dev-node MyTap
;proto tcp
proto udp
remote х.х.х.х 1194
;remote my-server-2 1194
;remote-random
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-GCM
#comp-lzo
verb 3
;mute 20
push "route 192.168.1.0 255.255.255.0"
push "route 172.22.24.0 255.255.248.0"

C:\Program Files\OpenVPN\config\ccd\client
iroute 192.168.1.1 255.255.255.0

ifconfig-push 10.8.0.8 10.8.0.1 255.255.255.252

Answer 1

Based on the comments, I decided to describe how it should work in theory. I specially wrapped it with such a tag so as not to bathe with the html list, it's a pain when Orthodox markdown is already done.

1. При поднятом туннеле между клиентом и сервером есть коннект по дефолту, ничего дополнительно делать не требуется.

Клиент > сервер
2. Чтобы дать клиенту доступ в сеть за сервером, надо (сделать все пункты):
  2.1. На сервере в конфиге OVPN сервера сделать пуш нужной подсети
  2.2. На сервере разрешить форвардинг между OVPN подсетью и локальной (которая за сервером)
2.x. Если за сервером несколько подсетей, повторить для каждой
3. Чтобы сети за клиентом дать доступ к сети за сервером надо сделать п.2 и далее два варианта (или/или):
  3.1. Если клиент является шлюзом для своей локальной сети
    3.1.1. На клиенте разрешить форвардинг между OVPN подсетью и локальной (которая за клиентом)
  3.2. Если клиент НЕ является шлюзом для локальной сети, надо выполнить п. 3.1.1 и
    3.2.1. На каждой машине в локальной сети (которая за клиентом) прописать роут до ВПН подсети через хост на котором установлен клиент
3.x. Если за клиентом несколько подсетей, повторить для каждой

Сервер > клиент
4. Чтобы дать серверу доступ в сеть за клиентом надо выполнить п.2 и
  4.1. На клиенте разрешить форвардинг между OVPN подсетью и локальной (которая за клиентом)
4.x. Если за клиентом несколько подсетей, повторить для каждой
5. Чтобы сети за сервером дать доступ к сети за клиентом надо сделать п.2, п.3 и (или/или):
  5.1. Если сервер является шлюзом для своей локальной сети
    5.1.1. На сервере разрешить форвардинг между OVPN подсетью и локальной (которая за сервером)
  5.2. Если сервер НЕ является шлюзом для локальной сети, надо выполнить п. 5.1.1 и
    5.2.1. На каждой машине в локальной сети (которая за сервером) прописать роут до ВПН подсети через хост на котором установлен сервер
5.x. Если за клиентом несколько подсетей, повторить для каждой

Клиент <> сервер
6. Чтобы сети и за клиентом и за сервером видели друг друга, надо сделать все пункты.

Еще важный и не всегда очевидный момент, подсети всех объединяемых локальных сетей не должны пересекаться, т.е. не должны быть одинаковыми или не входить одна в другую.

Answer 2

VPN connection on the client and server creates an additional virtual network adapter with its own IP address. The VPN software is only responsible for the traffic that gets inside the VPN. Everything else is configured by standard means: routing tables, firewalls, NAT. In openvpn, some routing table settings can (should) be specified in the VPN config, and not directly edit the tables in the OS. All this applies to any OS - the principles of openvpn are the same in Linux and Windows.
Usually the client config is made as "easy" as possible. They indicate only the necessary options for connecting to the server (protocol, server address and port, encryption and logging parameters). Everything related to routing between networks (route, push route) is removed from the server config.
Option push "route ..." - adds a route on the remote side. Those. if the option is specified in the server config, then the route is added on the client side.
To add a route on the server side in the server config, use the option: route
CCD files:
You do not have the correct syntax for the ifconfig-push option. The correct one is
: ifconfig-push client_ip mask
The server IP is not required.
In the iroute option, we specify the networks behind this particular client. These routes will be added to the server's routing table when the client connects. There is no need to duplicate these routes with the route options in the main server config.
You can also specify the push route option in the CCD file to add a route to the client for the network behind the server. Usually push route is specified in the main server config and it works for all clients.
But! In order for the networks behind the client and server to see each other, they must know which routes to send traffic to each other. If the VPN server and the VPN client are the default gateways for their networks, then there is no problem, the computers within the networks will send all traffic through them anyway. But if the VPN server and/or the VPN client are not the default gateways for their networks, then you need to add additional routes for neighboring networks through the VPN server/client. Routes can be centrally added via DHCP options, possibly AD policies.
Firewalls on any host can block traffic. To debug network interaction through VPN, I recommend first disabling firewalls on all test devices. After you configure the firewall routing, enable one at a time, immediately check the operation and make changes to the firewall rules, if necessary.
After you have achieved a connection between the VPN client and the server, everything else is the correct configuration of routing and firewalls.