Feature Request: Manual PMTU disable flag for DTLS

[Karl O. Pinc]

Hello,

I am not part of the openconnect core team.  That said,
I believe the best way to be sure that your request
is not forgotten is to file an "issue" at:

https://gitlab.com/openconnect/openconnect/-/boards#/

Please check first to see if a similar issue already exists.

The text of your request below should be sufficient.


Even better would be to code the enhancement yourself and
submit a patch as a "pull request".

However, before submitting a pull request it would not hurt to get a
response here, or in the issue you file, just in
case some developer is violently opposed to your
feature request, or wants a different user interface
(command line option name, in this case), or wants
some other change in the design.

I wouldn't think anyone would object, but as I
said I'm not a particularly active community member
so don't know for sure.


Requests sent to the mailing lists, without creating
an "issue", may well be forgotten.

On Wed, 1 Jul 2026 08:51:29 +0300
_ root_ <palko.v.ya at gmail.com> wrote:

> Feature Request: Optional PMTU Discovery Disable Switch for DTLS

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

Regards,

Karl <kop at karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein