VPN connected client unreachable from subnet

If the client can already reach the shares before connecting with L2TP/IPsec, then connecting via remote access creates a routing conflict.

Cheers - Bob

If the client can already reach the shares before connecting with L2TP/IPsec, then connecting via remote access creates a routing conflict.

Cheers - Bob

It looks like this: share is on 192.168.0.1, 192.168.0.2 and 192.168.1.2 are working on files on the share. 192.168.0.1 connects to the VPN, for 192.168.0.2 nothing changes 192.168.1.2 loses the connection to the share. It doesn’t make a difference if they try to connect to the share after the host connects to the VPN, 0.2 can access it, 1.2 can’t.

I still couldn’t figure it out, I think it might be a gateway problem, the VPN connection changes the default gateway and the host in a different subnet can’t reach this machine. The question is, is there a way in the UTM to handle this?

If there's nothing blocked in the Firewall log, then the problem has to be routing or DNS.  I can't "see" what's where though.  Maybe a simple diagram with IPs?

Cheers - Bob

There's nothing in the firewall log. This is how it looks like:

Clients from Subnet A and B are working on the share on the client in Subnet A. The client with the share connects through L2TP/IPsec to UTM2. For the clients from Subnet B the share disappears, for the clients from Subnet A nothing changes, they still have access.

I guess it's Routing and that there's a 192.168.1.0/24 subnet known to UTM2.  A route print on the command line of the client with the share would show that.

Cheers - Bob

thanks for the tip, there was a similar subnet on UTM2. I changed the ranges on UTM1 now it has 192.168.10.0/24 192.168.20.0/24, UTM2 has 192.168.0.0/24 192.168.1.0/24. I had high hopes but unfortunately the problem is still there even with this new ranges. This is what the route command shows on the client, left is VPN connected

The second line when connected shows that the user of the PC with the shares needs to de-select 'Use default gateway on remote network' in the IPv4 Properties of the L2TP client.  My preferred solution would be to use SSL VPN remote access to UTM2 with a Profile that has only 192.168.0.0/24 & 192.168.1.0/24 in 'Local Networks'.

Any better luck now?

Cheers - Bob

If I deselect the default gateway on remote network the client can't access the shares behind UTM2. I tried SSL VPN, for some reason the connection is very slow /15Mbit vs 160Mbit with L2TP/IPsec/ and now for a change the client has access to the internet through UTM2 but can't access the shares there /despite the fact that all related settings in UTM are identical with LPTP and with that it works/ and is still unreachable from inside UTM1. To the left is the L2TP/Ipsec connection, to the right the SSL VPN.

I'm getting really confused now ..:)

L2TP/IPsec causes these routing problems because WebAdmin has no idea what subnets are behind the VPN connection.  You need to add the following persistant route at the command line in the PC with the shares (for example):

route -p add 192.168.0.0 mask 255.255.254.0 10.242.2.1 metric 25

Cheers - Bob

Thank you very much, with the static route it's finally working! There is still one more problem, this route doesn't work after a reboot even though it a persistent one.. To the left are the routes after a reboot and to the right the working one if I remove and readd the line: