AW: OpenConnect does not take over MTU

[David Woodhouse]

On Wed, 2022-06-08 at 19:35 +0000, Schütz Dominik wrote:
> Hi,
> 
> sorry that the reply to the mail with the subject "Pulse with ESP has
> problems with Kerberos Tickets" and "OpenConnect does not take over
> MTU" took so long.
> 
> We have found out the following about MTU with OpenConnect and
> "protocol=pulse" (ESP):
> 
> With OpenConnect, the MTU of the virtual adapter (tun0) is always
> 1400, regardless of whether the MTU of the physical adapter is larger
> or smaller.
> 
> root at host1:~# ifconfig -a
> tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
> wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1300
> 
> root at host1:~# ifconfig -a
> tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
> wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
> 
> root at host1:~# ifconfig -a
> tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
> wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> 
> 
> The PulseUI (9.1.R14) dynamically adjusts the MTU of the tun0.


This is amazingly useful; thank you.

One thing is missing; we don't know how (or 'if') the client *tells*
the far end what the MTU should be.

If you could get a MITM capture and look for unknown attributes in what
their client sends to the server (or indeed in what the server sends
back), especially looking for those MTU values, it would be very much
appreciated.

Setting the MTU on *our* side is only half the equation.

We certainly *can* do that, of course, and we have the logic to fetch
the TCP MSS and subtract from it already for other protocols; we can
extend that to Pulse.

-------------- 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/20220608/5c62c692/attachment-0001.p7s>