One of my Road Warrior, OpenVPN clients is experiencing Windows File Explorer time-outs when trying to access shared folders on a Windows server on the “Green” network. Others are having no such difficulties.
Based on my research, it appears that I have an MTU problem. Here is my confusion:
- When I remote to the machine of the person having trouble and run "ping -f -l " the MTU discovered is 1472. The VPN is not connected.
- The OpenVPN server has always had the setting “tun-mtu 1472” in the server.conf file. I edited the user’s .ovpn config file to match that.
- When I connect the client machine to the OpenVPN server and run ping < Green network ip address of the Windows file server> -f -l " the MTU discovered is 1340. And I cannot access the shares on the Windows file server.
- So I change the MTU in the user’s .ovpn config file to 1340 and reconnected the VPN. There are some red lines in the connection dialog box about a mismatch in the MTU between the client and the server. But when the connection is made, I can now open/access the shared folders on the Windows server.
It’s not clear to me what is going on – why is the MTU dropping 132 bytes – and whether this represents a fix or a temporary work-around for the one user. Why don’t I have to do something similar for all the other users?
According to my research, a more “elegant” way to solve MTU issues this is to use mssfix. I tried that, but when I checked the mssfix box on the server and set the fragment size to 1400, all my users lost internet access and access to the file server. (Client configs do not allow split tunnels.) What if I add an “mssfix 1300” setting to client configs?