OpenVPN Support Forum

Hello!

Please, help me to understand what's going on.
One of my OpenVPN client's is before router which demands MTU to be lower than 1400:

Frag needed and DF set (mtu = 1400)

As I understand, OpenVPN client can not explain to it's server about client's PMTU problems, so I have to reduce MTU globally.
Since I use UDP as transport protocol manual assumes that I should try "mssfix" option. I set it to "mssfix 1300"

--mssfix max
Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. The default value is 1450.

But from client's log I see:

openvpn: Control Channel MTU parms [ L:1557 D:166 EF:66 EB:0 ET:0 EL:0 ]
openvpn: Socket Buffers: R=[163840->131072] S=[163840->131072]
openvpn: Data Channel MTU parms [ L:1557 D:1450 EF:57 EB:4 ET:0 EL:0 ]

May be client's version of OpenVPN 2.2.2 mips-openwrt-linux doesn't support "mssfix" option?

I was unable to recive big packets, like when downloading something from FTP server via tunnel without "mssfix" option.
Now I can, but I do not understand something:

Should "mssfix" option change MTU value of tun/tap interface? It's still set to 1500!
As I ping my OpenVPN client with packets bigger than what "mssfix" is set to, I do not get any PTMU warnings and these packets are lost of course.

#server pings client via tunnel:
ping -c 5 -s 1359 -M do 103.vpn
PING 103.vpn 1359(1387) bytes of data.
1363 bytes from 103.vpn: icmp_seq=1 ttl=64 time=277 ms
1363 bytes from 103.vpn: icmp_seq=2 ttl=64 time=296 ms
2 packets transmitted, 2 received, 0% packet loss, time 1677ms

ping -c 5 -s 1360 -M do 103.vpn
PING 103.vpn 1360(1388) bytes of data.
5 packets transmitted, 0 received, 100% packet loss, time 13999ms

#how tcpdump sees 1359 pings
14:45:20.482255 IP server > 103.vpn: UDP, length 1429
14:45:20.463170 IP 103.vpn > server: UDP, length 1429

But why is it 1429? Should not it be smaller because of mssfix limitation?
+I do not get it, why have I get these packets, isn't 1449>1400MTU?
+As I transfer filex via SCP, tcpdump says that packet lenght is 1285 in both directions.

Yeah, official manual, thats where I found out about "mssfix" option.
I'm more curious about "mtu-disc" option which turns on PMTUD.
But manual doesn't explains should it be used on server, client or both.
What "may be" exactly is and when is it better than "yes".

As I understand to get PMTU warnings inside of tunnel, I should change MTU values of tunnel interfaces, which means that have to change all clients configurations at once, or I could really use another instance for problem clients.

+I want to know how do I get [UDP, length 1429] packets with "mssfix 1300" option set.