Hello,
The reason the traffic won't go is because it exists outside of your VPN solution at the moment. The Teltonika client is given a virtual network interface with an IP in the internal VPN network range. So that's the extent of what it can reach until you do more.
For site to site we have a guide here that I strongly suggest you read through, and particularly the troubleshooting section where tools like tcpdump are used to confirm that packets are traveling to where you want them to go.
https://openvpn.net/vpn-server-resource ... in-detail/
But in short I can point out these issues:
The subnet 192.168.1.0/24 is too common. That means that if your client on the right in your diagram is on a 192.168.1.0/24 network as well, you may already have a subnet collision. It would be best to re-IP the subnet on the left on the Teltonika to something more unique like for example 10.77.55.0/24 or such. But assuming the local subnet on the right side VPN client is not 192.168.1.0/24 then in theory that is not the issue at the moment with your current setup.
The user account on the Access Server for the Teltonika device must have the 'VPN client gateway' function enabled, and the subnet 192.168.1.0/24 must be defined there (assuming that the subnet behind the Teltonika is 192.168.1.0/24). This way the Access Server will know that in order to reach 192.168.1.0/24 it has to go through the Teltonika device. Simply doing this SHOULD allow the Access Server itself to ping 192.168.1.0/24, assuming there are no firewall or configuration issues on the Teltonika itself.
And on the user account for the VPN client on the right, access should be granted to 192.168.1.0/24. That way, that VPN client will know that in order to reach 192.168.1.0/24 it has to go through the Access Server. And the Access Server knows to go through the Teltonika device to get to 192.168.1.0/24. In turn, the Teltonika device should already know how to reach VPN clients as that is part of the basic configuration.
There may be firewall and routing misconfigurations or subnet collisions that prevent things from working. For example, a Windows firewall may decide that 'out-of-scope' subnets (networks that it is not directly path of by itself) are to be dropped. Which could means packets from the Teltonika device may be dropped by the firewall on the VPN client. Likewise the Teltonika device may have firewalls enabled by itself that prevent traffic from crossing between VPN network and LAN network.
The guide I gave you contains troubleshooting where you can run tcpdump to monitor ping packets flowing between devices. I suggest you use that to see where the traffic goes and does not go.
Kind regards,
Johan
OpenVPN Inc.