MTU test fails with client v2.4.5

[sumpfralle]

Our wireless community uses OpenVPN.

In order to discover MTU problems, we use --mtu-test for determining the MTU size.

This worked well for years with various combinations of client and server versions (e.g. 2.2 and 2.3).

Currently we experience problems with a client v2.4.5-3 (part of OpenWrt v18.06). It fails to run the MTU test against any available server version (2.2, 2.3, 2.4).

Other OpenVPN clients (e.g. 2.3) work well with all server versions.

The client version 2.4.5 shows the following behaviour during the MTU test:

• an inactivity timeout (based on the keepalive setting of the server) is triggered: [example.org] Inactivity timeout (--ping-restart), restarting
• after prolonging the keepalive option from 10 60 to 60 400, the MTU test fails on the client with the following error message: failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).
• the server log does not exhibit any warnings or other messages

Thus there seem to be two issues that did not happen with older client versions:

• the client fails to recognize keepalive-pings during the MTU test
• the client fails to conclude the MTU test even with a prolonged keepalive timeout

All tests were conducted with IPv4 as well as IPv6.

I would appreciate hints for debugging this issue.
Thank you!

[Gert Döring]

Does this only happen with the OpenWRT builds, or can you reproduce with a "standard build" on Linux?

(The --mtu-disc code is something the current developers have pretty much "inherited", so we need to figure out how to test this first - and not having to crosscompile would certainly be a plus :-) )

[tct]

Replying to sumpfralle:

The client version 2.4.5 shows the following behaviour during the MTU test:

• an inactivity timeout (based on the keepalive setting of the server) is triggered: [example.org] Inactivity timeout (--ping-restart), restarting
• after prolonging the keepalive option from 10 60 to 60 400, the MTU test fails on the client with the following error message: failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).
• the server log does not exhibit any warnings or other messages

Is it possible you have misunderstood how --keepalive works ?

keepalive 60 400 means that:

• The client will not know it has been disconnected for 400 seconds
• The server will not know the client has disconnected for 800 seconds

A complete log at --verb 4 from the client would help clarify the issue.

[tct]

Replying to Gert Döring:

(The --mtu-disc code is something the current developers have pretty much "inherited"

--mtu-test not --mtu-disc

[Gert Döring]

Setting "version" and "milestone" correctly.

Though it's unclear this can be fixed if we get no feedback.

[Gert Döring]

So, there is indeed different things here.

--mtu-disc which got broken at some point due to build system changes (and nobody noticed) - this has been repaired in 2.4, 2.5 and 2.6 branches.

commit 4d63d15ef9e1eb34ffdc4028a96f506decced99c
Author: Gert Doering <gert@…>
Date: Tue Feb 22 12:38:32 2022 +0100

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

(for 2.4)

--mtu-test is using OCC messages of varying size to figure out the maximum data channel packet size that can be transmitted across a given connection. This should be working fine in 2.4 and 2.5, though it got broken in the pre-2.6 code base.

If it is indeed broken in 2.4 and 2.5 as well, we need a log on the current 2.4/2.5 version that displays what it is doing.

For 2.6, we "just" need someone to code the fix (and plaisthos is very busy fixing more critical stuff).