Routing from LAN into OpenVPN

I need to set up a route from our local network into our VPN. That is, anybody from inside the LAN should be able to communicate with machines in the VPN, without being a VPN client itself. Problem is, I'm somewhat of a dummy when it comes to networks...

The local network has an 8-bit range, 192.168.2.X The VPN server itself is in another network, on 192.168.3.20 (8-bit) The VPN network has a 16-bit range, 10.8.X.X

The eth0 interface of the machine running the openvpn server has a static IP at 192.168.3.20. The tun0 interface of the vpn server itself listens to 10.8.0.1

What we have already working is that packets to 10.8.x.x in the local network get rerouted to the server:

traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 60 byte packets
 1  gateway (192.168.2.1)  2.508 ms  2.364 ms  2.325 ms
 2  10.8.0.1 (10.8.0.1)  1.898 ms  1.895 ms  1.911 ms

So I can already ssh into it over 10.8.0.1, that's fine.

However, when I try to get to a client in VPN, the result is quite a bit different:

traceroute to 10.8.0.178 (10.8.0.178), 30 hops max, 60 byte packets
 1  gateway (192.168.2.1)  2.315 ms  2.152 ms  2.036 ms
 2  192.168.3.20 (192.168.3.20)  1.764 ms  1.760 ms  1.776 ms
 3  * * *
etc...

What bugs me a bit about that is that a direct request to the server terminates at 10.8.0.1, while I would have expected it to either not work, or terminate at 192.168.3.20. So obviously I don't understand too much of what's going on here...

Going from there, I thought I could solve the issue by forwarding traffic coming in on eth0 to tun0:

sudo iptables -A FORWARD -i eth0 -o tun0 -d 10.8.0.0/16 -j ACCEPT

But that didn't have any effect. And that's pretty much where I'm stuck. I tried a few variations of the above, and played around with route in the OpenVPN config, all without any visible change.

What is interesting though is that the trace activity actually shows up in the

*VPN log, but I don't understand much of what's going on here either:
Fri Oct 19 11:57:53 2018 us=219532 GET INST BY VIRT: 10.8.0.158 -> y18022c/185.184.117.20:1194 via 10.8.0.158
Fri Oct 19 11:57:53 2018 us=219539 y18022c/185.184.117.20:1194 TUN READ [60]
Fri Oct 19 11:57:53 2018 us=219544 y18022c/185.184.117.20:1194 TLS: tls_pre_encrypt: key_id=0
Fri Oct 19 11:57:53 2018 us=219555 y18022c/185.184.117.20:1194 ENCRYPT IV: 14c0471a 9fe7860f
Fri Oct 19 11:57:53 2018 us=219580 y18022c/185.184.117.20:1194 ENCRYPT FROM: 000000ae fa450000 3cac0400 000b1135 5ec0a803 010a0800 9e98b682 bf00282[more...]
Fri Oct 19 11:57:53 2018 us=219612 y18022c/185.184.117.20:1194 ENCRYPT TO: 14c0471a 9fe7860f 00bbfc72 b50c8915 8390d362 82f0a84c c22803b1 2a7ceca[more...]
Fri Oct 19 11:57:53 2018 us=219622 PO_CTL rwflags=0x0002 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219629 PO_CTL rwflags=0x0000 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219637 I/O WAIT Tr|Tw|Sr|SW [0/63574]
Fri Oct 19 11:57:53 2018 us=219646 PO_WAIT[0,0] fd=4 rev=0x00000004 rwflags=0x0002 arg=0x5654a4302150 
Fri Oct 19 11:57:53 2018 us=219652  event_wait returned 1
Fri Oct 19 11:57:53 2018 us=219658 I/O WAIT status=0x0002
Fri Oct 19 11:57:53 2018 us=219696 y18022c/185.184.117.20:1194 UDPv4 WRITE [101] to [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA c15dc78e ddd12705 8c3a860c 9cd9fe1e da29c4b2 14c0471a 9fe7860f 00bbfc7[more...]
Fri Oct 19 11:57:53 2018 us=219707 y18022c/185.184.117.20:1194 UDPv4 write returned 101
Fri Oct 19 11:57:53 2018 us=219715 PO_CTL rwflags=0x0001 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219722 PO_CTL rwflags=0x0001 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219730 I/O WAIT TR|Tw|SR|Sw [0/63574]
Fri Oct 19 11:57:53 2018 us=231770 PO_WAIT[0,0] fd=4 rev=0x00000001 rwflags=0x0001 arg=0x5654a4302150 
Fri Oct 19 11:57:53 2018 us=231782  event_wait returned 1
Fri Oct 19 11:57:53 2018 us=231789 I/O WAIT status=0x0001
Fri Oct 19 11:57:53 2018 us=231799 UDPv4 read returned 53
Fri Oct 19 11:57:53 2018 us=231809 GET INST BY REAL: 185.184.117.20:1194 [succeeded]
Fri Oct 19 11:57:53 2018 us=231837 y18022c/185.184.117.20:1194 UDPv4 READ [53] from [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA 1196c495 845bb7fd e61cc8d8 ed4d427a b901d6c8 e81fe5a9 3ab1acce b5687f0[more...]
Fri Oct 19 11:57:53 2018 us=231846 y18022c/185.184.117.20:1194 TLS: tls_pre_decrypt, key_id=0, IP=[AF_INET]185.184.117.20:1194
Fri Oct 19 11:57:53 2018 us=231859 y18022c/185.184.117.20:1194 DECRYPT IV: e81fe5a9 3ab1acce
Fri Oct 19 11:57:53 2018 us=231876 y18022c/185.184.117.20:1194 DECRYPT TO: 00000036 fa2a187b f3641eb4 cb07ed2d 0a981fc7 48
Fri Oct 19 11:57:53 2018 us=231897 y18022c/185.184.117.20:1194 PID_TEST [0] [SSL-0] [>EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:53 0:54 t=1539943073[0] r=[0,64,15,0,1] sl=[11,53,64,528]
Fri Oct 19 11:57:53 2018 us=231905 y18022c/185.184.117.20:1194 RECEIVED PING PACKET*

My biggest problem is really that I have no idea what exactly is going on here... Why is a request to 10.8.0.1 not routed through 192.168.3.20? I mean, it would be logical that it has to go through the actual server before terminating at the VPN...? And when requests are arriving at eth0 (as is evident by 192.168.3.20 showing up in the trace), why aren't they forwarded to tun0? Is openVPN itself blocking something here?

I've insufficient points to comment but I'd like to know how you have 192.168.2.X and 192.168.3.X connected? At a guess what you need is to push the routes for 192.168.3.X back to the other end of the VPN. In the /etc/openvpn/server.conf add the route to 192.168.2.X: (You probably already have the 192.168.3.X network in there)

# /etc/openvpn/server.conf
# Router Subnet
route 192.168.3.0 255.255.255.0
push "route 192.168.3.0 255.255.255.0"
# The other local Subnet that you need to tell the far end about
route 192.168.2.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"

Now provided that the the local vpn server is the default gateway for the LAN each side should be able to route to the other.

Is this what you mean?