This issue is only affecting users connecting to our UTM's L2TP VPN connection on Windows devices. Users are able to establish the connection, but when they do so, they lose access to network drives that have been mapped via Group Policy. This issue only occurs over VPN. When the device connects to the domain on our LAN, the drives maps as expected.
As a workaround, I have remounted the drives and assigned them another letter to be used while using the VPN. Very possible this is a Microsoft issue, but I wanted to check with you all as the issue is only occurring over the VPN.
The error message is
Personally, I've never done that because GPO just works the way it works and that is "not consistent"
I've just had a users batch file run to map the drives. This has been an issue I…
Are you sure this isn't a DNS issue? Can you reach your mapping through IP address of the server instead of host name? If you can access the same share using IP, then it's a DNS issue and you need to add your VPN Pool to the Allowed Network listing on Sophos.
try using \\IP_Address\<share name> instead of \\DNS_Name\<share name>
UTM - 9.706 | Intel i3-4150 4th Gen Processor 16GB Memory | 500GB SATA HDD | GB Ethernet x5
BAlfson Thank you so much. This looks like an incredible resource and I will certainly be sure to give it a good look through and attempt to do some testing. I will also give that NAT rule a go and to rule out Windows Firewall.
Amodin Almost positive this is not a DNS issue as the same fileshare point mounts when I manually assign the drive path with the DNS share name an alternative drive letter locally on the device i.e GPO mounts the fileshare point at D:\\DNSfilesharename\folder....workaround= I manually assign the fileshare point to Z:\\DNSfilesharename\folder
This workaround appears to be permanent. It is only the fileshare points that mounts and is assigned a drive letter through GPO that remain disconnected over the VPN connection. Before these GPO mounted fileshare points stay connected just fine over VPN.
We are missing something here... Amodin is saying, have you tried with IP or notGPO has nothing to do with your problemWhile you are connected with L2TP, ping the "DNSfilesharename" and post only the result
Ol DedaI just pinged the "DNSfilesharename" over L2TP and received back a successful reply.
Pinging *DNSfilesharename* with 32 bytes of data:Reply from 10.0.X.X: bytes=32 time=124ms TTL=127Reply from 10.0..X.X bytes=32 time=135ms TTL=127Reply from 10.0.X.X bytes=32 time=87ms TTL=127Reply from 10.0.X.X bytes=32 time=69ms TTL=127
I see the dns resolves the hostname. Windows tries to remap the drive i think, i never used map drive from gpo
I've just had a users batch file run to map the drives. This has been an issue I've seen since Y2K at least. We had to end up running the batch to disconnect all mapped drives, ipconfig /flushdns, then remap the drives. Sucks, but it worked.
Thank you very much for providing me with this history. I've only been in System Administration for 6 months. I was a technician for 5 years before this. So while I had some working knowledge of GPOs, I wasn't building, deploying, and troubleshooting policy issues.
It sounds like you are pretty convinced that this is a Windows issue unrelated to the UTM specifically. This makes me feel like I should let the issue go and that I'll just end up chasing red herrings if I start looking deeper into the wireshark/tcpdump logs. Maybe I'm wrong about that, though.
I was messing around with the netstat commands to resolve the issue at one point. I think, in a fashion similar to what you are suggesting. But it became too complicated once the VPN layer was introduced. And I wasn't convinced the GPO would run consistently enough to push out the .bat file at the exact right time needed to unmount and remount the drives once the connection was broken.
Manually reassigning the drives a different letter has proved to be a viable workaround. The drive stays mounted whether or not the user is connected over VPN.