I did not test your patch, though I assume it would work, because I did not want to reinforce the idea that the VPN gateway is doing something wrong. Instead, I continued my own investigation. It turns out that in gnutls 3.5.8, gnutls_dtls_get_data_mtu() does not return the same value that was passed to gnutls_dtls_set_data_mtu(): Trying to set DTLS MTU to 1301 DTLS MTU (data) is 1291 Trying to set DTLS MTU to 1302 DTLS MTU (data) is 1307 I assume this is because when gnutls_dtls_get_data_mtu tries to recover the data mtu from the internal mtu, it calculates the overhead based on the currently set internal mtu, not the originally requested data mtu. If the padding for those sizes is different, the wrong result will be returned. I guess the next step is to try to report this to gnutls, if anyone agrees with my interpretation of the issue. I think that openconnect should try to detect over-large incoming DTLS packets and log or discard them. It might also be nice to detect truncated IP packets, but that would involve introspection into the tunneled IP packets that it doesn't have to do now. -------------- next part -------------- A non-text attachment was scrubbed... Name: dtls_try_ensure_mtu.patch Type: text/x-patch Size: 1784 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20180106/f811c8eb/attachment.bin>
