Vpn messing with network mapped drives

Joust

Supreme [H]ardness
Joined
Nov 30, 2017
Messages
6,309
Ok. So I added an inexpensive Dell switch (left unmanaged, should just be a dumb hub) to my setup.

Setup:
Fiber point => sophos box (gateway, DHCP, firewall) => dell 5424 switch => workstation

Now, I'm running a VPN on the workstation. It appears to drop my networked drives (volumes on a NAS/SAN connected to the Dell switch)

I think the correct method of action is to add a route to the table of the workstation as follows:

route -p add [172...destination of server ip] mask 255.255.255.255.255 [172...gateway ip]

Is that accurate? These mapped drives are costing me a TON of time when they drop off.
 
Define VPN. If this is something like a corporate VPN then it may very well be that split tunneling is disabled by the VPN owner, we do this with our remote users, and everything routes through the vpn despite your routing table. Otherwise you should already a route for directly attached networks which is you imply with your example route.
 
First, that mask is wrong and has an extra .255

Second, you are adding a static route to a server that appears to be on the same subnet as your workstation. You don't want that traffic to go to the gateway as it's not destined to an external network. Traffic to the servers in the same subnet should not need to be routed, and hit the resource directly.

Finally, since the second item isn't working, it looks like the previous poster is correct. Your VPN is connecting with split tunnel disabled, so it's routing 100% of your traffic to the VPN gateway, not your internal gateway. If this is the case, and you do not control the VPN, there is nothing you can do to fix. A local static route will be ignored, as the VPN software route will always take priority.
 
Define VPN. If this is something like a corporate VPN then it may very well be that split tunneling is disabled by the VPN owner, we do this with our remote users, and everything routes through the vpn despite your routing table. Otherwise you should already a route for directly attached networks which is you imply with your example route.
Not a corporate VPN. Commercial.
 
First, that mask is wrong and has an extra .255

Second, you are adding a static route to a server that appears to be on the same subnet as your workstation. You don't want that traffic to go to the gateway as it's not destined to an external network. Traffic to the servers in the same subnet should not need to be routed, and hit the resource directly.

Finally, since the second item isn't working, it looks like the previous poster is correct. Your VPN is connecting with split tunnel disabled, so it's routing 100% of your traffic to the VPN gateway, not your internal gateway. If this is the case, and you do not control the VPN, there is nothing you can do to fix. A local static route will be ignored, as the VPN software route will always take priority.

I was on a roll with the .255's, bro.

Maybe I'm just screwed. The VPN doesn't support split tunneling natively, but I think windows can force it to an extent. I'll look more into it, I suppose. Big pain in my butt.
 
I was on a roll with the .255's, bro.

Maybe I'm just screwed. The VPN doesn't support split tunneling natively, but I think windows can force it to an extent. I'll look more into it, I suppose. Big pain in my butt.

Nope, you will not be able to fix this on the windows side. That would defeat the security of the VPN application, making it useless for corporate environments that cannot allow split tunneling (my company does this as well). But I also make sure not to use the company device for anything personal, so it's not an issue.
 
Then you are going to have to clarify your VPN setup, client and server side. I was not under the impression you were using the windows VPN client or had any control over the VPN configuration. If you do have control of both, then it's just figuring out where to change the settings, then you won't need to mess with adding any local routes on your workstation.
I have minimal control. Very minimal.

However, I don't see that the problem could be anything else. VPN enabled - intermittent disconnect from mapped drives. VPN not enabled, rock solid.
 
I have minimal control. Very minimal.

However, I don't see that the problem could be anything else. VPN enabled - intermittent disconnect from mapped drives. VPN not enabled, rock solid.

I'd do a tracert against the fileserver IP. It should show you if it's going to the VPN gateway, which has no idea how to route those packets.

An easier test is to google "what's my IP" in both states (connected to VPN and disconnected). The IPs will not match if split tunneling is disabled.
 
I'd do a tracert against the fileserver IP. It should show you if it's going to the VPN gateway, which has no idea how to route those packets.

An easier test is to google "what's my IP" in both states (connected to VPN and disconnected). The IPs will not match if split tunneling is disabled.
I am 100% certain that the IP's don't match. The point is, there's nothing else that should bugger the mapped network drives.
 
Gents, I thank you all. I believe I am getting the problem narrowed down. The network drive is failing, and a short while later the FreeNAS box GUI stops responding, but still pings, and SSH works. Eventually it also stops communicating.

I think it's related to a memory leak, rather than a network issue.

Once again, I appreciate the insight you all have provided.
 
Back
Top