MTU on public wifi

[Brian Candler]

I was testing wireguard via a public wifi service (Icomera on-train 
wifi) and found that the tunnel MTU wireguard had chosen was too large: 
TCP connections got stuck as soon as any large amount of data was sent 
(e.g. just running "top")

The MTU of the wifi service itself is 1440:

MacBook-Pro-2:~ $ ping -s1412 -D 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1412 data bytes
1420 bytes from 8.8.8.8: icmp_seq=0 ttl=58 time=46.006 ms
1420 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=40.847 ms
^C
--- 8.8.8.8 ping statistics ---
[Interface]
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 40.847/43.427/46.006/2.579 ms
MacBook-Pro-2:~ $ ping -s1414 -D 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1414 data bytes
556 bytes from 10.101.2.1: frag needed and DF set (MTU 1440)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src Dst
  4  5  00 a205 33b6   0 0000  40  01 e44d 10.101.2.227 8.8.8.8

(Payload 1412 + 20 bytes IP header + 8 bytes ICMP header = 1440)

The client is macOS wireguard-tools/wireguard-go.  Wireguard itself had 
set an MTU on utun1 of 1440.  With some experimentation, I found that 
setting MTU of 1400 was fine, but 1410 was too big.

With "MTU = 1400" in wg0.conf it now appears to work correctly, although 
I'm not sure how safe that value is - does Wireguard compress data 
before encapsulation, and therefore is there a chance that worst-case 
encapsulated packets could still be too big?

But I did try "dd if=/dev/urandom bs=1024 count=100" and it did send the 
whole random splurge without locking up the TCP connection.

I also wonder if wireguard could automatically reduce its MTU in 
response to ICMP "frag needed" packets, at least down to a configured 
minimum?

Regards,

Brian Candler.