OpenConnect does not take over MTU

[David Woodhouse]

On Mon, 2022-05-23 at 19:02 +0000, Schütz Dominik wrote:
> Hello,
> 
> By default, I have an MTU of 1400 with OpenConnect and
> "protocol=pulse" for tun0 (also with "protocol=nc").
> However, if I specify an MTU of 1360, nothing changes with tun0. What
> could be the reason for this?
> The PulseUI gets the MTU dynamically from the Pulse server.
> OpenConnect does not do this?

OpenConnect *should* get the MTU from the Pulse server. If you run with
'-vv' do you see the debug message from around line 370 of pulse.c:

		vpn_progress(vpninfo, PRG_DEBUG,
			     _("Received MTU %d from server\n"),
			     new_ip_info->mtu);

I would *guess* so because AFAICT it'll *abort* if it doesn't receive
both an MTU *and* at least one of Legacy IP and/or IPv6 addresses.

Is the server giving you an MTU of 1400 in your examples, then? It's
interesting that it's giving the PulseUI client a different MTU.

Did you manage to set up MITM to watch the traffic? I wonder if there's
something we need to *send* in order to make the server calculate the
MTU differently? In the Cisco protocol we send our idea of the MSS over
the public network, as the 'base MTU'.

It looks like our `--mtu` argument doesn't actually do anything for
protocols other than AnyConnect; that's a bit of an oversight. I think
it should be imposed as a *minimum*; if the server offers anything
larger, we should clamp down to what is passed with the --mtu argument.
Although that's only really enforceable on the *uplink*; the server may
well send us packets however large it likes. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20220523/f25a30af/attachment-0001.p7s>