Client reports Windows Explorer closes sporadically when browsing shared VPN LAN folders, MTU setting to blame...?

EvanVanVan

[One would think that with the 1000's of threads pertaining to MTU settings, I could figure out what the hell it should be, but after searching and searching I'm still very confused.]

To quickly recap my situation, I set up a VPN server last month in a FreeNAS jail. A user connects fine most of the time, but reports that sometimes they'll be browsing a shared folder on the server's LAN and all of a sudden the Windows Explorer menu will close entirely. Typically this happens when they are using the Explorer - Preview Pane to preview documents.

The server's logs show some PID_ERR replay-window backtrack errors.

Connection specs:
Server: 150/150 (Verizon FiOS) - Speedtest.net: 170/175 (typical)
Client: 1 gigabit/1 gigabit (supposedly) (From their local ISP, VTel) - Speedtest.net: 735/650 (again pretty typical)
Client connected to Server with redirect-gateway def1: Speedtest.net: 141/24 - A significant decrease in the upload speed obviously, and results in hundreds of PID_ERR Large Diff errors.

Here are the specs of the FreeNAS box the OpenVPN server is run on:
SUPERMICRO MBD-X9SCL-F-O Intel Xeon E3 Server
Intel Xeon E3-1230 V2
Kingston Technology ValueRAM 32GB DDR3 1600MHz PC3 12800 ECC.

I've attached my server and client config files but doing some searching I see a bad MTU setting can often be the source of random glitches. I assumed the server's 150/150 connection could handle (to an extent) the settings in the https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux guide, so right now the MTU is set to 48000. There are guides online stating "how easy it is to determine the proper MTU," but they instruct to start at 1500 and subtract 10 until you find a working value. The starting point seems so dramatically different than the numbers suggested in the Gigabit Networks guide? Anyway, I've tried tun-mtu 1470 (the first successful ping that goes through using those guides) and the client's internet was unusable. I also tried tun-mtu 9000, which worked much better than 1470 but didn't seem to offer any improvement over tun-mtu 48000.

Any advice on the cause of these issues or what I can do to fix them?

Additionally, a few hours ago I tried switching the server to use proto tcp-server/client. Since then I've had no replay-window backtrack errors, also when the client ran a speedtest while connected to the server the results were 108/139 without any PID_ERR large diff errors.

Thank you

# Protocol #
#------------------------------------------------
dev tun
dev tun0
topology subnet
proto udp
port 1011

# Routes #
#------------------------------------------------
server 10.1.0.0 255.255.255.0
ifconfig 10.1.0.1 255.255.255.0

# Client Config #
#------------------------------------------------
# ccd-exclusive 1
# ifconfig-pool-persist /etc/openvpn/clients/ipp.txt
# client-config-dir /etc/openvpn/clients/

# Pushed Routes #
#------------------------------------------------
push "route 192.168.74.0 255.255.255.0"
push "dhcp-option DNS 192.168.97.1"
# push "dhcp-option WINS 192.168.1.1"
push "dhcp-option NTP 129.6.15.30"
push "redirect-gateway def1"
push "dhcp-option DNS 10.1.0.1"

# Encryption #
#------------------------------------------------
# Diffie-Hellman:
# dh /etc/ssl/openvpn/dh2048.pem

# PKCS12:
# pkcs12 /etc/ssl/openvpn/vpn-server.p12

# SSL:
cipher AES-256-CBC
auth SHA512
# tls-auth /etc/ssl/openvpn/ta.key 0
# key-direction 0

# TLS:
tls-server 1
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-ECDH-RSA-WITH-AES-256-CBC-SHA384:TLS-RSA-WITH-AES-256-CBC-SHA256:!aNULL:!eNULL:!LOW:!3DES:!MD5:!SHA:!EXP:!PSK:!SRP:!DSS:!RC4
remote-cert-eku "TLS Web Client Authentication"

# Logging #
#------------------------------------------------
log-append /tmp/openvpn.log
status /tmp/openvpn-status.log
verb 5

# Connection Options #
#------------------------------------------------
keepalive 10 120
comp-lzo yes

# Connection Reliability #
#------------------------------------------------
# client-to-client 1
persist-key 1
persist-tun 1

# Connection Speed #
#------------------------------------------------
sndbuf 393216
rcvbuf 393216
fragment 0
mssfix 0
tun-mtu 48000

# Pushed Buffers #
#------------------------------------------------
push "sndbuf 393216"
push "rcvbuf 393216"

# Permissions #
#------------------------------------------------
user nobody
group nogroup
chroot jail

# chroot #
#------------------------------------------------
# chroot should be utilized in case the VPN is ever exploited; however, most commercial
# routers don't have internal flash storage large enough to support it. An OpenVPN
# chroot would be ~11MB in size.

# Modify if chroot is configured #
#--------------------------------------------
ccd-exclusive 1
ifconfig-pool-persist "/var/chroot-openvpn/etc/openvpn/clients/ipp.txt"
client-config-dir "/var/chroot-openvpn/etc/openvpn/clients"

cipher AES-256-CBC
dh /var/chroot-openvpn/etc/ssl/openvpn/dh2048.pem
pkcs12 /var/chroot-openvpn/etc/ssl/openvpn/vpn-server.p12
tls-auth /var/chroot-openvpn/etc/ssl/openvpn/ta.key 0
key-direction 0 # Config Type #
#------------------------------------------------
client

# Connection #
#------------------------------------------------
dev tun
proto udp
remote xxxxx.no-ip.org 1011

# Speed #
#------------------------------------------------
fragment 0
mssfix 0
tun-mtu 48000

# Reliability #
#------------------------------------------------
comp-lzo
float
nobind
persist-key
persist-tun
resolv-retry infinite

# Encryption #
#------------------------------------------------
auth SHA512
auth-nocache
cipher AES-256-CBC
pkcs12 vpn-client1.p12
remote-cert-eku "TLS Web Server Authentication"

tls-auth ta.key 1
key-direction 1

# Logging #
#------------------------------------------------
verb 5

EvanVanVan

Bueller? Bueller? [Lol that is the other thing about 1000s of "mtu settings" posts, many of them have no replies]

I don't really believe setting tun-mtu is just throwing darts at a dart board and hoping one hits... If the max mtu that pings successfully for me with

ping -n 1 -l XXXX -f [server ip]

is 1470, how does the Gigabit's guide setting of 9000/48000/etc. even work? (although it does).

Do I have to change the mtu settings of the routers or something? Any help would be appreciated...

So far things have been much more stable with TCP, but I'd like to go back to UDP if I can get it working properly...

Thank you

Jlennemann

UDP is connectionless oriented and does not verify if the packet has been delivered. TCP is connection oriented and verifies the packet has been delivered to the distant end. The MTU settings will play a major role in your connection. Typically you want the MTU settings to match on the local and distant end. Your main concern is your distant end user is having issues viewing the shared drive files. Is there a reason why you have "redirect-gateway" active? If you're only wanting the VPN for the distant end user access to the shared drives then redirect-gateway is not needed. You can achieve what you're trying to do with a split tunnel. Right not you have a full VPN tunnel that is routing all information through the VPN and then out. This includes web browsing, ect.

EvanVanVan

Thank you for the reply.

I enabled redirect-gateway mostly for security purposes while the users are traveling. Quite often they're on the road and using public wifi. Typically I advise them not to do any banking or other high risk browsing during that time, but I figured if I could route everything through my server it would be much safer and more convenient for them. Of course now that I'm writing this I realize I probably have to rethink my MTU/gigabit settings anyway, obviously public wifi is far from gigabit speeds...

I'll definitely try removing the redirect-gateway though and see if things improve... I can always give them a second config file to use on the road and possibly setup a second server for it to connect to.

Thanks for the help

Jlennemann

Before you do anything try changing the MTU size back to the default and see what happens. I had an issue where users could log into their domain machines but when accessing their shared drives they magically disappeared. The issue was an incorrect mtu setting on the local end. The distant end was set to jumbo 9000 and the local end was at 1500.