cannot ping from other subnet (client-to-client config, tun)

beroduar

I have tried to find an answer by studying the available tutorials and books, but I need to ask for help here.
I need to connect computers in the following way:

Win10 client1(192.168.43.123)>gateway(192.168.43.100)>>ISP1(NAT)>>OpenVPN server (public IP x.y.z.a, Ubuntu on a VPS)>>ISP2(NAT)>gateway(192.168.0.1)>win7(or Ubuntu) client2(192.168.0.2)

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push “192.168.43.0 255.255.255.0”
#client-to-client #uncommenting this has not changed the ping behaviour
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
auth SHA256
dh dh.pem
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 4

IPTABLES rules on the server :
iptables -A FORWARD -s 10.8.0.4 -d 10.8.0.8 -j ACCEPT
iptables -A FORWARD -s 10.8.0.8 -d 10.8.0.4 -j ACCEPT

The clients connect to the server properly, they are given addresses 10.8.0.4 (client2) and 10.8.0.8 (client1) respectively.
I can see "/sbin/ip route add 192.168.43.0/24 via 10.8.0.1" in the server response
I can ping 10.8.0.1, 10.8.0.4, 10.8.0.8 from 192.168.0.2 (in fact from both clients)
I cannot ping 10.8.0.0 (which I understand is a proper behaviour)
but I cannot ping 192.168.43.123 from 192.168.0.2 and I do need to connect to this computer

My Kernel IP routing table under linux:
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 100 0 0 enp3s0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp3s0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 enp3s0
192.168.43.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun0

commenting/uncommenting client-to-client on the server config file will not change the ping behaviour on the client

I understand it is the routing which is not properly configured , but I have no idea how to solve this.
May I ask you for a clue, please?

TinCanTech

beroduar wrote I have tried to find an answer by studying the available tutorials and books

I am curious to know which books you studied ?

But you clearly have not read the openvpn Howto.
https://community.openvpn.net/openvpn/wiki/HOWTO

beroduar

Many thanks for your interest, however I am not completely sure if this answers my question.
I am not an IT and I would really appreciate some more elaborative answer.
The available documentation (howto, "Mastering OpenVPN "by Eric F Crist/Jan Just Keijser do not cover exactly my scenario)
I understand I need to adapt the available documentation and I probably will have to, however I believe there are good people around, who exactly know what I am doing wrong and may make my life easier.
But anyways thanks for your post.

P.S.
I have implemented ccd files (with ifconfig-push , iroute, push "route...") for both the clients that setup the clients ips, push the routes for the both subnets and inform the server of the routing to the subnets .
I can see the routes to the counterparting client that are setup on both computers (still cannot ping the computers)
(I understand the client-to client adds non-IP based communication between clients and is not much related to the tun itself.)
I can see (on Windows machine) routing the 192.168.43.0 to the 10.8.0.2 , which I do not understand.
On the linux client I can see the following 192.168.43.x ping response : "From 10.8.0.1: icmp_seq=2 Redirect Host(New nexthop: 10.8.0.2)"
So my question is :how to setup the correct routing through the 10.8.0.1, not the 10.8.0.2 ?

TinCanTech

https://community.openvpn.net/openvpn/wiki/HOWTO#IncludingmultiplemachinesontheclientsidewhenusingaroutedVPNdevtun

The HOWTO wroteThe last step, and one that is often forgotten ...

Read that part.

TinCanTech

beroduar wrote my question is :how to setup the correct routing through the 10.8.0.1, not the 10.8.0.2 ?

You cannot because that would be incorrect.

From the OpenVPN --server point of view all client addresses are routed via x.x.x.2

This is how OpenVPN works.