If I remove these routes on the server, I loose connection from the vpn-server to the vpn-client.
No change in situation on the vpn-client, no ping to lan clients.
Results of further investigations:
- switching vpn protocol to tcp does not change anything
Info of arp when vpn is up:
on the vpn-client router:
IP address HW type Flags HW address Mask Device
xx.x.x.x 0x1 0x2 xx:xx:xx:xx:xx:xx * wwan0
xx.xxx.xxx.xxx 0x1 0x2 xx:xx:xx:xx:xx:xx * wwan0
192.168.2.194 0x1 0x2 xx:xx:xx:xx:xx:xx * br-lan
192.168.2.22 0x1 0x2 xx:xx:xx:xx:xx:xx * br-lan
the last two entries are the clients on the lan, which can not be pinged
on one of the clients (ip address 192.168.2.22 at enp0s25):
_gateway (192.168.2.1) at xx:xx:xx:xx:xx:xx [ether] on enp0s25
? (192.168.2.2) at <incomplete> on enp0s25
So this means, that the address resolution at least works. But that's all.
It looks like 192.168.2.0/24 is being reused by more than one VPN client. If there is more than one VPN client connecting to this server, all the clients need separate certificates with unique CNs, because that name is how the OpenVPN server identifies them in the client config directory. Also for proper routing back to client LANs, the LAN of every client needs to be a different subnet from any other in the network.
That was it!
I thank your very much for this hint!
I was near to fall into despair! Used so many hours to find the cause without success.
How came it to this situation:
I setup a 2nd router device for spare and made an extra entry for it on the vpn-server. And even if only of the two devices was active at one time, the entry caused the problem.
A very bad pitfall!
I am very happy that it is solved now.
Again many thanks to you and also to psherman, who tried to help me with big patience.
Best regards,
woec
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.