Ball of confusion: MTU, mssfix and fragment
Posted: Tue Feb 23, 2021 6:09 pm
I'm running OpenVPN 2.5 on the server and clients. The server is running ipFire.
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 (LAN). Other Road Warriors are having no such difficulties.
Based on my research, it appears that I have an MTU problem. Based on tests of the OpenVPN server it has (always had) the setting “tun-mtu 1472” in the server.conf file. Here is my confusion...
When I remote to the machine of the person having trouble to determine the MTU, pinging from the client machine to the public IP of the LAN gateway, without the VPN connected, the MTU is also 1472.
Here is the user’s .ovpn config file:
But, when I connect the VPN on the users machine, it's still not able to access the file server shares. So I checked to see what the MTU was between the client and the file server with the VPN connected. The MTU for that connection turns out to be 1340!?
So I changed the "tun-mtu 1472" line in the user’s .ovpn config file to "tun-mtu 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 appears that MTUs can be volatile. Is editing the client.ovpn file the right way to deal with MTU volatility? According to my research, a more “elegant” way to solve MTU issues (especially volatility) 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 access to the file server.
What if I leave "tun-mtu 1472" and instead add an “mssfix 1300” setting only in the client configs? Is that going to be a better solution for dealing with "volatile" MTUs and clients have different MTUs? Am I misunderstanding this stuff? Thanks.
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 (LAN). Other Road Warriors are having no such difficulties.
Based on my research, it appears that I have an MTU problem. Based on tests of the OpenVPN server it has (always had) the setting “tun-mtu 1472” in the server.conf file. Here is my confusion...
When I remote to the machine of the person having trouble to determine the MTU, pinging from the client machine to the public IP of the LAN gateway, without the VPN connected, the MTU is also 1472.
Here is the user’s .ovpn config file:
Client Config
#
#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto udp
tun-mtu 1472
remote xxx.xxx.xxx.xxx 1194
pkcs12 jqpublic.p12
cipher AES-256-CBC
auth SHA512
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name xxx.xxx.xxx.xxx name
mssfix 0
#---------------------------
# Start of custom directives
# from client.conf.local
#---------------------------
auth-user-pass
auth-nocache
#---------------------------
# End of custom directives
#---------------------------
#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto udp
tun-mtu 1472
remote xxx.xxx.xxx.xxx 1194
pkcs12 jqpublic.p12
cipher AES-256-CBC
auth SHA512
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name xxx.xxx.xxx.xxx name
mssfix 0
#---------------------------
# Start of custom directives
# from client.conf.local
#---------------------------
auth-user-pass
auth-nocache
#---------------------------
# End of custom directives
#---------------------------
But, when I connect the VPN on the users machine, it's still not able to access the file server shares. So I checked to see what the MTU was between the client and the file server with the VPN connected. The MTU for that connection turns out to be 1340!?
So I changed the "tun-mtu 1472" line in the user’s .ovpn config file to "tun-mtu 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 appears that MTUs can be volatile. Is editing the client.ovpn file the right way to deal with MTU volatility? According to my research, a more “elegant” way to solve MTU issues (especially volatility) 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 access to the file server.
What if I leave "tun-mtu 1472" and instead add an “mssfix 1300” setting only in the client configs? Is that going to be a better solution for dealing with "volatile" MTUs and clients have different MTUs? Am I misunderstanding this stuff? Thanks.