AW: OpenConnect does not take over MTU

[Schütz Dominik]

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.

root at host1:~# ifconfig -a
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1200
wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1300

root at host1:~# ifconfig -a
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1300
wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400

root at host1:~# ifconfig -a
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1392
wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

root at host2:~#
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1360
wlp110s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

See also the following extract from the PulseSecure article "https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB21481"

# Network Connect / Pulse Desktop prior to 5.2R2
Calculation of the MTU size for the virtual adapter is determined by the local physical interface of the client machine. The virtual adapter will be 100 bytes less than the local physical adapter.

# Pulse Secure Desktop 5.2R2 and above
Pulse Secure Desktop 5.2R2 retrieves the negotiated MSS value from the TCP control channel and uses it to calculate a more accurate MTU for the virtual adapter. This improvement was made to help avoid UDP ESP fragmentation when traversing networks as Pulse is able to evaluate the max MTU size across the network instead of evaluating only the local interface.


# The following formula should therefore be added for OpenConnect so that the correct MTU is always taken over (see "https://docs.pulsesecure.net/WebHelp/PCS/9.1R1/AG/Content/PCS/PCS_AdminGuide_9.1R1/Using_the_Advanced_Client.htm"):

Basically the formula used to calculate the virtual adapter MTU is:
MIN (Physical Adapter MTU, MTU from PCS, TCP MSS value + 40)


If the correct MTU is set for tun0, we had no problems setting up an ESP session with OpenConnect and the problems with the Kerberos tickets did not occur afterwards.

Regards,
Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6003 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20220608/7579797c/attachment.p7s>