Feature Request: Manual PMTU disable flag for DTLS

[_ root_]

Feature Request: Optional PMTU Discovery Disable Switch for DTLS

Hello,

While using OpenConnect, I encountered a DTLS PMTU Discovery issue on
one of my network locations.

On another location, using the same VPN server and the same version of
OpenConnect, DTLS works perfectly. However, on this particular route,
PMTU Discovery does not function correctly.

The issue is neither caused by OpenConnect nor by the VPN server.

Traffic to my VDS passes through networks operated by different ISPs,
hosting providers, transit operators, routers, and international
backbone carriers. At any point along this path, ICMP "Fragmentation
Needed" messages may be filtered, blocked, or never generated. In
addition, some networks deploy DPI or other networking equipment that
may also interfere with proper PMTU Discovery.

The Internet is not a single, homogeneous network with consistent
rules. It is a collection of independent networks, each with its own
routing and filtering policies. End users have no control over the
infrastructure of transit providers, hosting companies, or ISPs and
therefore cannot restore proper PMTU Discovery when it is broken
somewhere along the route.

For this reason, I would like to request an optional command-line
switch to manually disable PMTU Discovery, for example:

--disable-pmtu

I am not asking to remove PMTU Discovery or change the current
OpenConnect behaviour.

On the contrary, PMTU Discovery should remain enabled by default,
because in properly configured networks it provides the best
performance and automatically selects an appropriate packet size.

However, when PMTU Discovery cannot function correctly due to network
conditions outside the user's control, the user should have the
ability to disable it manually and use a fixed MTU via the existing
options (--base-mtu or --mtu) without modifying OpenConnect's source
code or maintaining a custom build.

In my case, manually selecting the MTU completely resolves the DTLS
instability. The only missing piece is a supported way to disable PMTU
Discovery without patching the OpenConnect source code.

Such an option would:

preserve the current default behaviour of OpenConnect;

keep PMTU Discovery as the recommended operating mode;

make disabling PMTU an explicit and conscious user choice;

allow OpenConnect to operate reliably in networks where PMTU Discovery
cannot function correctly due to conditions outside the control of
both the client and the VPN server;

eliminate the need for users to maintain custom source code patches
solely to disable this functionality.

I believe this would be a useful enhancement that would not affect
existing users while significantly improving OpenConnect's flexibility
in real-world network environments with various routing and filtering
limitations.

Thank you for considering this proposal.

Note

This report was translated into English with the assistance of AI
because I do not have sufficient English proficiency to write
technical reports.

However, all ideas, observations, test results, and conclusions
presented here are entirely my own and are based on practical
experience using OpenConnect. AI was used solely as a translation and
wording assistance tool.