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@host1:~# ifconfig -a > tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1400 > wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1300 > > root@host1:~# ifconfig -a > tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1400 > wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1400 > > root@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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
