Opened 4 years ago

Last modified 6 weeks ago

#1103 new Bug / Defect

MTU test fails with client v2.4.5

Reported by: sumpfralle Owned by: plaisthos
Priority: minor Milestone: release 2.4.11
Component: OSS OpenVPN Clients Version: OpenVPN 2.4.5 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: MTU
Cc: plaisthos

Description

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!

Attachments (2)

openvpn-server.conf (426 bytes) - added by sumpfralle 4 years ago.
openvpn-client.conf (289 bytes) - added by sumpfralle 4 years ago.

Download all attachments as: .zip

Change History (7)

Changed 4 years ago by sumpfralle

Attachment: openvpn-server.conf added

Changed 4 years ago by sumpfralle

Attachment: openvpn-client.conf added

comment:1 Changed 4 years ago by 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 :-) )

comment:2 in reply to:  description Changed 3 years ago by 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.

comment:3 Changed 3 years ago by tct

Replying to Gert Döring:

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

--mtu-test not --mtu-disc

comment:4 Changed 22 months ago by Gert Döring

Milestone: release 2.4.5release 2.4.11
Version: OpenVPN 2.4.5 (Community Ed)

Setting "version" and "milestone" correctly.

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

comment:5 Changed 6 weeks ago by Gert Döring

Cc: plaisthos added

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).

Note: See TracTickets for help on using tickets.