--mtu-disc yes not supported on Linux

[harri]

If I set "--mtu-test yes" on Linux, then openvpn ignores the man page and claims

{root@cecil:openvpn (master) 530} /usr/sbin/openvpn --cd /etc/openvpn --config client.conf --mtu-disc yes
Sat Jul  1 15:24:46 2017 OpenVPN 2.4.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun 30 2017
Sat Jul  1 15:24:46 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Enter Private Key Password: ******
:
Sat Jul  1 15:24:52 2017 --mtu-disc is not supported on this OS
Sat Jul  1 15:24:52 2017 Exiting due to fatal error
{root@cecil:openvpn (master) 531} uname -a
Linux cecil.afaics.de 4.11.8-raw #1 SMP PREEMPT Thu Jun 29 22:46:23 CEST 2017 x86_64 GNU/Linux

Address family is AF_INET.

[tct]

cc

[harri]

PS: Of course the title should have been "--mtu-disc yes not supported on Linux", sorry for the typo.

[David Sommerseth]

I've corrected the title.

[Antonio Quartulli]

This is happening because openvpn-2.4 implements some kind of "AF family" socket guessing.
Because of this, the attribute used by the mtu-disc logic to understand if the socket is IPv4 or IPv6 is not set (because it is guessed) when it should be.

As a temporary workaround you can explicitly set the socket to be IPv4 or IPv6 by using udp4 or udp6 as protocol specifier in your client configuration.

Fixing the real problem might require some more time.

[harri]

Does "mtu-disc no" make sense for IPv6 at all? Maybe this option should be silently ignored for IPv6.

[MatejKovacic]

Hi,

"As a temporary workaround you can explicitly set the socket to be IPv4 or IPv6 by using udp4 or udp6 as protocol specifier in your client configuration."

How to do that?

[Antonio Quartulli]

Replying to MatejKovacic:

Hi,

"As a temporary workaround you can explicitly set the socket to be IPv4 or IPv6 by using udp4 or udp6 as protocol specifier in your client configuration."

How to do that?

"by using udp4 or udp6 as protocol specifier in your client configuration."

You have an option "proto" in your config and that can be set to "udp4" or "udp6". You can also have a look at the man if you want a deeper explanation.

[MatejKovacic]

Thank you.

Anyway, I am using TCP, so should say:

proto tcp4

[Gert Döring]

So, I've finally found time to look into --mtu-disc in various versions, in the context of #1452.

Turns out that the functionality was totally not there in 2.4.11 or 2.5.5 (it would accept the option, but not react on incoming ICMP Packets) - this will be fixed for "socket over IPv4" for 2.4.12 and 2.5.6.

I'm not sure how why earlier 2.4 would report "not supported on this OS" as there do not seem to be any fixes to that in the release/2.4 tree in git... cannot reproduce this error for either IPv4 or IPv6.

For IPv6 sockets, this was never implemented, and will be made available in 2.6.0.

Sooo... please upgrade to 2.4.12 or 2.5.6 (even better) to get working --mtu-disc yes.

The patch in question is

commit 4225114b96723bdecd68398f7a89765879b31b5d (master)
commit 3e0c506e5d9135ef4b08547db8679cc5bd2a7582 (release/2.5)
commit 4d63d15ef9e1eb34ffdc4028a96f506decced99c (release/2.4)
Author: Gert Doering
Date: Tue Feb 22 12:38:32 2022 +0100

Fix --mtu-disc maybe|yes on Linux.

[Gert Döring]

Just rebuilt 2.4.3 on gentoo / 4.19.9 - cannot reproduce. It does not *work* (due to the autoconf bug fixed in #1452), but it does not abort either.

So I assume that it was some combination of local libraries / headers and 2.4.3, and I do not think it's worth pursueing.

[Gert Döring]

The "wontfix" is for the specific 2.4.3 behaviour observed.

--mtu-disc yes itself has been fixed in the 2.4, 2.5 und master/2.6 branches.