This is a classic and frustrating problem that’s almost always related to how the application, the Windows file sharing protocol (SMB), and the VPN client interact. The fact that it works perfectly on the local network confirms that the core issue isn’t permissions or the application itself, but something in the communication path over the VPN.
Here’s a breakdown of the likely causes and some troubleshooting steps you can take:
The Saving Process Explained
To understand the problem, you need to know how many applications save a file to a network location. It’s often more complex than just “overwriting” the file. A typical process looks like this:
Create a temporary file: The application creates a new temporary file (like ~WRL0001.tmp) in the same directory as the original file.
Write data to the temporary file: The program writes all the new data to this temporary file.
Delete the original file: The program deletes the old project file.
Rename the temporary file: The temporary file is renamed to the original project file’s name.
This process is designed to prevent data loss in case of a crash during the save, but it’s also where things can go wrong over a less-than-perfect network connection like a VPN.
Potential Culprits and Solutions
Antivirus and Security Software: This is one of the most common causes. Antivirus software, both on the client machine and the file server, can interfere with this process. When the program creates the temporary file, the antivirus might scan it. When the program tries to delete and rename the files, the antivirus might hold a lock on them, causing the application to hang.
Solution: Temporarily disable the antivirus on a test client and see if the problem goes away. If it does, you’ll need to configure your antivirus to either exclude the specific application, the shared network path, or to disable “on-rename scanning” if that’s an option. Check the antivirus on both the client and the server.
SMB Protocol Issues over VPN: The SMB protocol, which Windows uses for file sharing, is chatty and can be sensitive to latency and dropped packets. While you said you have no packet loss, a slight delay in a response from the server can cause the client application to time out or freeze.
Solution: Disable TCP Autotuning. This is a fix that has worked for many people with similar issues, especially with older versions of Windows. TCP AutoTuning is a feature that optimizes network traffic, but it can sometimes be too aggressive and cause problems over high-latency connections.
Open Command Prompt as an administrator on the affected client machine.
Run the command: netsh interface tcp set global autotuninglevel=disabled
Restart the computer and test. You can re-enable it later with netsh interface tcp set global autotuninglevel=normal.
Application-Specific Saving Methods: The program itself might have a unique way of saving that doesn’t play well with the VPN. Some programs have options like “save in the background” or “fast save” that you can toggle.
Solution: Check the program’s settings for any options related to file saving or network behavior. See if there are any known issues with that specific program and saving over a WAN connection.
VPN-Specific Configuration: Even if the VPN itself is “unrestricted,” there could be a setting that’s affecting file transfers. Some VPNs have a split-tunneling configuration, where only traffic destined for the corporate network goes through the VPN. Other settings related to MTU size (Maximum Transmission Unit) can also cause issues.
Solution: If possible, try a different VPN client or protocol (e.g., switch from OpenVPN to IKEv2 or vice-versa) to see if the behavior changes. Check the MTU settings on the client and the VPN server. An MTU mismatch can cause fragmentation and slow down or halt a file transfer.
Local Caching Issues: Windows has a feature called “Offline Files” that can cache network files locally. If this is enabled, it can cause conflicts when a user is connected via VPN and tries to save.
Solution: Check if “Offline Files” is enabled for the shared folder on the client’s machine. You can find this in Sync Center in the Control Panel. If it is, consider disabling it for that specific share.
Your Next Steps
Test for Antivirus Interference: This is the most likely culprit. Find a user with the problem and temporarily disable their client-side antivirus. If it fixes it, you’ve found your source.
Try the TCP Autotuning Fix: This is a very low-impact change to try and has a high success rate for this kind of issue.
Reproduce the Problem with a Network Monitor: If the simple fixes don’t work, you’ll need to dig deeper. Use a tool like Wireshark on the client machine to capture network traffic during the failed save attempt. This will show you exactly what is happening (or not happening) between the client and the server and may reveal a timeout or a specific error message.
Check Server-Side Logs: Look at the event logs on the Windows file server for any errors or warnings that occur at the time of the failed save. This might reveal a permissions or locking issue that isn’t immediately