On Tue, Aug 15, 2017 at 12:30 PM, David Woodhouse <dwmw2 at infradead.org> wrote: > On Tue, 2017-08-15 at 11:42 -0700, Daniel Lenski wrote: >> + mtu = ( base_mtu - UDP_HEADER_SIZE - ESP_OVERHEAD >> + - (vpninfo->hmac_key_len ? : 20) /* biggest supported MAC (SHA1) */ >> + - (vpninfo->enc_key_len ? : 32) /* biggest supported IV (AES-256) */ ); >> if (vpninfo->peer_addr->sa_family == AF_INET6) >> mtu -= IPV6_HEADER_SIZE; > > Better... except that you left the padding hard-coded to 16. That would > be the same as the cipher blocksize (== IV size).... except you don't > actually *need* to be pessimistic. It can be calculated exactly, just > as dtls_get_data_mtu() does in openssl-dtls.c > > From payload MTU, add at least 1 byte of padding, round up to the next > multiple of the blocksize. Add the MAC size, and other headers. That's > the packet on the wire. > > So from wire packet MTU, subtract headers and MAC and IV, round *down* > to a multiple of blocksize, subtract one byte for the *minimal* > padding, and that's the largest payload you can carry. Aha, thanks, I'll look at dtls_get_data_mtu() and try to get this exactly right. One frustrating thing about GP is that I literally have *no clue* what the MTU "inside" the VPN looks like. At least one user has reported (https://github.com/dlenski/openconnect/issues/43) that the VPN is much faster when using --mtu with a value that's several times higher than the apparent "wire MTU." Which means that fragmenting and reassembling packets between the local host and the VPN gateway is significantly more efficient than passing the smaller packets through. -Dan
