I configured a VPN tunnel to link two sites. The client machine sees the whole subnet on the other sites, but other machines on the same LAN (on the client side) can’t access the remote (server side) subnet. Is there a way to achieve that ?
Basically I’d like each machine on both sides of the tunnel to be able to communicate with each other.
Thanks
My config
CLIENT SIDE :
db vpn show
cbrass=tunnel
AuthMode=certificate
Cipher=
Compression=disabled
Digest=
Mode=routed
Protocol=udp
RemoteHost=°°°.°°.°°.°
RemotePort=1273
Topology=subnet
status=enabled
SERVER
db vpn show
brass=openvpn-tunnel-server
Cipher=
Compression=disabled
Digest=
LocalNetworks=10.10.10.0/24
RemoteNetworks=10.10.1.0/21
Network=10.246.103.0/24
Port=1273
Protocol=udp
PublicAddresses=°°°.°°.°°.°
TlsVersionMin=
Topology=subnet
status=enabled
Update : I reproducted the setup in a virtual lab and all is working as expected.
I observed that the routing table was wrong. I’ll try to rebuild the tunnels to see if it helps. Anybody have an idea why the relevant routes aren’t created ?
Are there any differences on subnets between virtual lab and real setup?
(Normally remote subnets of IPSec and OpenVPN are added into trusted networks automatically and not showed on static routes)
I used only /24 subnets until now for VPN-connected sites, but don’t think that this would change anything into using VPN.
Unless OpenVPN has some implementation issues on Nethserver (just guessing…)
Would you please share the subnets of LANs for both sides of your VPN?
Okay. 192.168.55.0/21 is really not valid. That explains why the route wasn’t created (silently). And shows that as usual the problem reside between the chair and the keyboard.
Now I’ll configure my lab with the same adresses as my production machines because I’m pretty sure that their ip configuration is correct.
Did some tests.
Route do not appears with 192.168.55.0/21. But appears with 192.168.48.0/21 which is a valid /21 subnet id (i was helped by a subnet calculator) @pagaille would you give a shot? Validator should refuse the remote network anyway (it’s unroutable and route refuses it) but at least could solve your issue.
The network subnet I was referring to (10.10.1.0/21) is definitively NOT valid. One must refer to 10.10.0.0/21 !
Furthermore there is a log file in /var/log/openvpn/nameofthetunnel.log that shows you that something wrong happens.
Probably the UI could be improved :
The subnet should be more thoroughly validated to keeps stupid noobs like me to enter invalid data.
The UI should report the warning that is displayed only in a somewhat hidden log (I was expecting that the logs would be shown in the usual messages log.
Thanks @pike for pointing me to the right direction !
Apologies to @giacomo for the non-existent bug
It was - again - a great issue on a great platform to learn a lot.