Do I have an MTU Issue?

[revmarkp]

I'm having problems with UDP clients having the connection freeze or hang when moving large files (eg using sftp in Thunar). I strongly suspect this is an MTU issue, as time and again, that's what pointed to in this and other forums. Nevertheless I can't seem to sort it, perhaps because I'm not getting the corrective config options right?

View OriginalServer Config

#OpenVPN 2.3.14 i386-portbld-freebsd10.3 on pfSense
dev ovpns2
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local x.x.x.x
tls-server
server 192.168.x.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server2
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user xxxxxxxxxxxxxx= false server2 1195" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'certX' 1"
lport 1195
management /var/etc/openvpn/server2.sock unix
max-clients 2
push "route 192.168.x.0 255.255.255.0"
push "route 192.168.x.0 255.255.255.0"
duplicate-cn
ca /var/etc/openvpn/serverX.ca
cert /var/etc/openvpn/serverX.cert
key /var/etc/openvpn/serverX.key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/serverX.tls-auth 0
comp-lzo adaptive
persist-remote-ip
float
topology subnet

View OriginalClient Config

#OpenVPN 2.3.10 x86_64-pc-linux-gnu OpenSSL 1.0.2g
dev tun
persist-tun
persist-key
cipher AES-128-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote X.X.X.X 1195 udp
verify-x509-name "certX" name
auth-user-pass
pkcs12 pfsense-udp-1195-XXXX.p12
tls-auth pfsense-udp-1195-XXXX-tls.key 1
ns-cert-type server
comp-lzo adaptive
mssfix 1200

To workaround this in the short term I've created a TCP server, which although much slower is stable and works fine.

I was hoping mssfix would be the answer, but it seems not. I've tried settings on 1400, 1200 and 1000. Each time a large file transfer hangs after about 15%.

MTU Test:

Code: Select all

Empirical MTU test completed [Tried,Actual] local->remote=[1557,1557] remote->local=[1557,1557]

(get same results from a number of remote client locations/connections)

Should I try lower number with the mssfix? How low?!
Is --fragment part of the solution? That needs to be server as well as client side right?

[TinCanTech]

Logs ..

Please see:
HOWTO: Request Help ! {2}

[revmarkp]

Sorry for no logs, network info, etc, my bad Didn't scroll down the 'HOWTO request help' far enough!

Coming back soon with that info, but as I tested it just now no error, grrrr.

[revmarkp]

Despite my best efforts I cannot now replicate my previous problem. Sorry to waste time. The only change I made to my test scenario was to convert my previous UDP server into a TCP one, and then create a new UDP server on port 1195. Will post back if I figure out what was going on.