How do I give access to all LAN machines to a OpenVPN tunnel? --> Route is not created when using a subnet other than /24

NethServer Version: 7.6
Module: OpenVPN Tunnel

Hi,

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 :slight_smile:

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

I think you need to create another tunnel and inverting client and server

Server A -> Client B
Client A <- Server B

In one installation I do it and it works… or you can use IPsec Net2Net tunnel and automatically you’ll contact both networks.

Regards

thanks Federico… Is it me or that’s really an ugly solution ? :smile:

I might have found the solution.

On the server side, there is a field named “Remote networks”. The helps says :

List of remote networks behind the client firewall which will be available to local hosts.

So I set up the IP range on my network on the client side.

I’ll test tomorrow. I was put on track by reading that article : https://help.endian.com/hc/en-us/articles/115003509367-Set-up-an-OpenVPN-Net2Net-Connection?mobile_site=true

Why use client and not Net2Net?

1 Like

Personally that’s what’s I’m doing : an OpenVPN net2net tunnel, but still there is a client connecting to a server to create the tunnel :slight_smile:

BTW, my solution doesn’t work. Should I use the bridged mode ?

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)

1 Like

Indeed. 255.255.248.0 on one of the sides.

Matthieu G. (en mode mobile)

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?

1 Like

@pike, you were right !! The routes are not correctly created when using subnets other than /24.

With a subnet /21 (server side) :

# db vpn show
tunnel=openvpn-tunnel-server
    Cipher=
    Compression=disabled
    Digest=
    LocalNetworks=192.168.65.0/24
    Network=10.223.25.0/24
    Port=1279
    Protocol=udp
    PublicAddresses=10.0.1.67
    RemoteNetworks=192.168.55.0/21
    TlsVersionMin=
    Topology=subnet
    status=enabled

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 enp0s3
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s3
10.223.25.0     0.0.0.0         255.255.255.0   U     0      0        0 tuntunnel
192.168.65.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8 

With a subnet /24 :

# db vpn show
tunnel=openvpn-tunnel-server
    Cipher=
    Compression=disabled
    Digest=
    LocalNetworks=192.168.65.0/24
    Network=10.223.25.0/24
    Port=1279
    Protocol=udp
    PublicAddresses=10.0.1.67
    RemoteNetworks=192.168.55.0/24
    TlsVersionMin=
    Topology=subnet
    status=enabled

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 enp0s3
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s3
10.223.25.0     0.0.0.0         255.255.255.0   U     0      0        0 tuntunnel
**192.168.55.0    10.223.25.2     255.255.255.0   UG    0      0        0 tuntunnel**
192.168.65.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8

The route to 192.168.55.0 is only present when using a /24 subnet.

@giacomo I think that’s a bug :slight_smile:

1 Like

The bug looks to be in openvpn actually. I checked the configuration files created, they look okay.

Furthermore, there is a significant noise on the internet when querying about openvpn and routes not created.

Still investigating.

Update. I tried to add the route manually, but it doesn’t work using the /21 subnet.

# ip route add 192.168.55.0/21 via 10.223.25.2 dev tuntunnel
RTNETLINK answers: Invalid argument

# ip route add 192.168.55.0/24 via 10.223.25.2 dev tuntunnel
                            ^^
# route 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 enp0s3
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s3
10.223.25.0     0.0.0.0         255.255.255.0   U     0      0        0 tuntunnel
192.168.55.0    10.223.25.2     255.255.255.0   UG    0      0        0 tuntunnel
192.168.65.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s8

:roll_eyes::sweat::grimacing::exploding_head:

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.

As far is i were able to find, the correct subnet id should be 192.168.48.0/21… Anyway i always shrunk netmasks, never expanded.

So @pagaille can I change the category of the topic from “Bug” to “Support”?

Right @giacomo right now I can’t say it’s a bug :slight_smile: I did it, will keep you updated.

Thank you Matthieu!

If you still have problems with the UI, take a look to an existing issue on the OpenVPN validator: https://github.com/NethServer/dev/issues/5736

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.

Actually this was (surprisingly :wink: ) my fault.

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 :

  1. The subnet should be more thoroughly validated to keeps stupid noobs like me to enter invalid data.
  2. 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 :slight_smile:

It was - again - a great issue on a great platform to learn a lot.

1 Like