How can I change the MTU of a Cisco Anyconnect VPN?

On my macOS 10.15 I have to use the Cisco AnyConnect Secure Mobility Client 4.8 to connect to the VPN of my university.

The connection is much slower than usual, probably because the MTU of 1300 is set too low.

Using the command ifconfig, i get this information about the connection:

utun2: flags=80d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1300 inet ###.###.##.## --> ###.###.##.## netmask 0xfffffe00 inet6 ###::####:###:###:###%utun2 prefixlen 64 scopeid 0x10 inet6 ###:####:#:#::### prefixlen 128 nd6 options=201<PERFORMNUD,DAD>

^{(IP addresses have been anynomized with #)}

How can I change this? I found nothing in the settings of the Cisco Client, not even in the configuration files.

A change in the system settings is of no use, via the terminal I tried the following:sudo ifconfig utun2 mtu 1470

The correct value is then displayed using the ifconfig command, but the connection itself does not change (neither the speed, nor the MTU value displayed here ). After reconnecting, the MTU is again registered at 1300.

How can I change the MTU effectively and permanently?

1 Answer

Since VPN encapsulation adds additional overhead to packets, reducing Maximum Transfer Units below the standard 1500 byte ethernet frame MTU helps to ensure that encapsulated packets are not fragmented.

To check for packet fragmentation, ping with the "do not fragment" switch can be used.

On my version of ping, MacOS High Sierra, I can specify a sweep size with the following options:

nevin% ping -g 1200 -G 1500 -D <remote host>

This gives a result:

1472 bytes from x.x.x.x: icmp_seq=64 ttl=48 time=108.894 ms 556 bytes from 192.168.2.1: frag needed and DF set (MTU 1492) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 d505 f712 0 0000 40 01 2739 192.168.2.111 x.x.x.x

My en0 MTU is 1500, but the response above is that my router has an MTU of 1492.

"Path MTU Discovery" will attempt to keep packet sizes below the fragmentation threshold of any link between two hosts, though this works best when ICMP is not being blocked along the way. (If you just begin to lose packets without any error messages, then ICMP is being blocked at some upstream point, and this might be the cause of your slow speeds: The remote host might be sending packets > than your local MTU, but not getting errors to tell it to scale back.

In short, trying to increase the size of MTU will not improve your performance.