Change of MSSFIX_DEFAULT breaks OpenVPN for some users

[MartinSpiessl]

Describe the bug
I recently upgraded from Ubuntu 22.04 (OpenVPN 2.5.11) to Ubuntu 24.04 (OpenVPN 2.6.14) and observed that my OpenVPN connection established via NetworkManager stopped working (connection was established, but SSL and SSH sessions become unresponsive after larger packages were dropped). After looking a bit into it, I found out that the default MTU was to blame. I needed to manually reduce the MTU from the default of 1500 to work with my provider (German 1&1, DSL, FritzBox 7590 as router (though that should not matter)). It seems like my provider has a threshold of 1452 bytes:

$ ping -c 1 -M do -s 1500 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1452

(Addendum: it works fine if I initiate the VPN while connected to a hotspot from my mobile phone (Vodafone Germany), it looks like their MTU is 1492)

Lowering the MTU to 1400 fixed the VPN for me (--tun-mtu 1400), but it took me a while to debug this and was not a pleasant user experience. I got curious what might have caused this break, first thinking about NetworkManager, but that was not the culprit, as it uses default values if not instructed otherwise. I moved on to the OpenVPN code base and currently think the problem is to blame on the following commit/line, which is present in v2.6.14 (Ubuntu 24.04) but not in v2.5.11 (Ubuntu 22.04):

0d86da3#diff-56a343af9d1cad371a0776185663d147dd46e610038114f0fae77310e2fe8ddaR80

- #define MSSFIX_DEFAULT     1450
+ #define MSSFIX_DEFAULT     1492

The commit message is well crafted and also explains the rationale behind this particular change:

1492 was picked in our community meeting for being a very common
encapsulation upper bound.

Expected behavior
A value should be chosen that works by default for a majority of users. The old values seems to have accounted specifically for this (1450 is "1452 minus epsilon", and 1452 seems to be a common values when you google it), so I am not sure what led the community to this change.

To Reproduce
Try establishing a VPN connection on a OpenVPN version that contains said commit with an infrastructure that can only handle a MTU of 1452 bytes.

Additional Information
I was able to fix the problem for myself, I report this mainly because I think you might want to know about the fact that this change indeed breaks stuff for people. So there will be no further pressure from my side to change that value (though I think it would be a good idea). Also happy to provide more details or run simple tests if you instruct me how to.

[schwabe]

You cannot compare the old value with the new value as there has been since the whole calculation has been changed in that patchset.

And if you read the commit message carefully you will see that it actually lowers the MTU for IPv6.

Please also to figure out what mss fix value actually works for your setup. So far you bug report is just saying that the mssfix default change broke your setup and you changed a different value (tun-mtu) to fix it again.

[MartinSpiessl]

You cannot compare the old value with the new value as there has been since the whole calculation has been changed in that patchset.

I read the commit carefully, and I think the default calculation is still comparable. I did not set fragment, and mssfix is still enabled with the default value before and after that commit, so the only difference should be that value (unless there are other commits later on that affect this).

And if you read the commit message carefully you will see that it actually lowers the MTU for IPv6.

I read it, but I cannot find this in the commit message, it merely states:

The current default is 1450, which translates to 1478 byte packets for udp4 and 1498 byte packets for udp6

Maybe I do not fully unterstand what the mssfix value is used for, is it the target or the

Regarding the right mss fix value that would work for me, I would love to set mssfix to determine the, but NetworkManager currently does not have the option, it only has a checkbox that will add --mssfix (without value) if toggled, but there is no input field, it is currently just a check box:
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/blob/main/properties/nm-openvpn-editor.c?ref_type=heads#L2168
There is code that would handle a numeric value though:
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/blob/main/src/nm-openvpn-service.c?ref_type=heads#L1879

I do not know how to spawn openvpn without going over NetworkManager, when I try to adjust the openvpn command that NetworkManager spawns I do not seem to get it to work ( I hit "Certificate does not have key usage extension" and "VERIFY KU ERROR", tried various flags, but this seems complicated).

[schwabe]

I read the commit carefully, and I think the default calculation is still comparable. I did not set fragment, and mssfix is still enabled with the default value before and after that commit, so the only difference should be that value (unless there are other commits later on that affect this).

No it is not. The old code is basically set mssfix 1450 while the new default is mssfix 1492 mtu.

NetworkManager currently does not have the option

please open a bug report with NetworkManager then please.

I do not know how to spawn openvpn without going over NetworkManager, when I try to adjust the openvpn command that NetworkManager spawns I do not seem to get it to work ( I hit "Certificate does not have key usage extension" and "VERIFY KU ERROR", tried various flags, but this seems complicated).

That sounds like your ovpn configuration was broken but Networkmanager ignores some of the config. You probably should figure out why/if Networkmanager strips out options that do stricter server checks.