Why isn't traffic routed through the OpenVPN client?

Question

openvpn

The point is this.
There is one OPSsense in two branches:

1. has a static external address, is an OpenVPN server, followed by the network 10.10.5.0/24, the address in the tunnel is 10.0.8.1,
   
2. connects to the Internet via PPPoE, is a client, behind it is the network 192.168.5.0/24, the address in the tunnel is 10.0.8.2.
   

The connection type in the OpenVPN settings on both is site-to-site, the network is allocated 10.0.8.0/24, OSPF is configured through the tunnel, they exchange routes (I don’t push static routes using OpenVPN, because the plans include dynamic routing between branches).
Pings from end to end of the tunnel go from both sides, from the client side the network that arrived in OSPF behind the server is pinged, but from the server side the network behind the client is not pinged. The firewall on both gateways allows all traffic in the tunnel and all traffic in the advertised networks.
Here are the routing tables:

gateway 1

default            *WAN_GW*      UGS      vtnet0
8.8.4.4            *WAN_GW*      UGHS     vtnet0
8.8.8.8            *WAN_GW*      UGHS     vtnet0
10.0.8.0/24        10.0.8.2           UGS      ovpns1
10.0.8.1           link#7             UHS         lo0
10.0.8.2           link#7             UH       ovpns1
10.10.5.0/24       link#2             U        vtnet1
10.10.5.1          link#2             UHS         lo0
*WAN_NET*     link#1             U        vtnet0
*WAN_IP*      link#1             UHS         lo0
127.0.0.1          link#4             UH          lo0
192.168.2.0/24     10.10.5.254        UGS      vtnet1
192.168.2.1        10.10.5.254        UGHS     vtnet1
192.168.2.2        10.10.5.254        UGHS     vtnet1
192.168.5.0/24     10.0.8.2           UG1      ovpns1
208.67.220.220     *WAN_GW*      UGHS     vtnet0
208.67.220.222     *WAN_GW*      UGHS     vtnet0

gateway 2

default            *WAN_GW*      UGS      pppoe0
10.0.8.0/24        10.0.8.1           UGS      ovpnc1
10.0.8.1           link#7             UH       ovpnc1
10.0.8.2           link#7             UHS         lo0
10.10.5.0/24       10.0.8.1           UG1      ovpnc1
*WAN_GW*      link#8             UH       pppoe0
*WAN_IP*      link#8             UHS         lo0
127.0.0.1          link#4             UH          lo0
192.168.5.0/24     link#2             U          alc0
192.168.5.1        link#2             UHS         lo0
208.67.220.220     *WAN_GW*      UGHS     pppoe0
208.67.222.222     *WAN_GW*      UGHS     pppoe0

OpenVPN configurations:

gateway 1

dev ovpns1
verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local *WAN_IP*
tls-server
server 10.0.8.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/1
ifconfig 10.0.8.1 10.0.8.2
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'vpn.rosta.su' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
ca /var/etc/openvpn/server1.ca 
cert /var/etc/openvpn/server1.cert 
key /var/etc/openvpn/server1.key 
dh /usr/local/etc/dh-parameters.2048
crl-verify /var/etc/openvpn/server1.crl-verify 
tls-auth /var/etc/openvpn/server1.tls-auth 0
topology subnet

gateway 2

dev ovpnc1
verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local *WAN_IP*
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote *ШЛЮЗ_1* 1194
ca /var/etc/openvpn/client1.ca 
cert /var/etc/openvpn/client1.cert 
key /var/etc/openvpn/client1.key 
tls-auth /var/etc/openvpn/client1.tls-auth 1

From gateway 1 with tcpdump, I see that the ping to 192.168.5.1 is sent from interface 10.0.8.1, i.e., as intended. I don't see these packets on the other end.
Who is not too lazy to read this footcloth, poke into the error, please.
Thank you.
UPD. When scanning nmap 192.168.5.1 -Pn says host up, but all 1000 ports are closed on it. How this is possible with the current firewall setting (all traffic in the LAN and tunnel is allowed) is not clear.
UPD2. From the 192.168.5.1 side, pfctl -si returns 0 blocked packets and 0 received packets.

Answer 1

Karoch.
If you add an option
to a file with the name *CN of the client* in the client-config-dir, then the network starts to ping. It turns out that the OpenVPN process on the client side needs to be directly told - route this network. It does not suit me, it is necessary that it spreads automatically. Maybe there are other options for encrypted site-to-site VPNs with normal routing? IPSec is suitable for such purposes?