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 from10 60
to60 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)
Change History (7)
Changed 4 years ago by
Attachment: | openvpn-server.conf added |
---|
Changed 4 years ago by
Attachment: | openvpn-client.conf added |
---|
comment:1 Changed 4 years ago by
comment:2 Changed 3 years ago by
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 from10 60
to60 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
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
Milestone: | release 2.4.5 → release 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
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).
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 :-) )