On Wed, Aug 1, 2018 at 4:43 AM, Jeroen Balduyck
<jeroen.balduyck at gmail.com> wrote:
> Alright, I did get confirmation that the interface on the server side
> is 1340 MTU when the tunnel gets established. But that was all but
> certain. I have 1322 MTU on Opnsense (FreeBSD). So in my mind this is
> a 100% MTU-mismatch.
Yes, I'm pretty sure this is caused by openconnect client not
tolerating *compressed* packet that are larger than the negotiated
MTU. If you can rebuild the client with the patch I sent subsequently
("Tolerate packets that are larger than negotiated MTU after
decompression"), this should allow it to tolerate the mismatch.
Similar patches have done the trick for other protocol variants in the
past.
Obviously, figuring out why the server and client have arrived at
different MTUs and resolving that will be useful? but with so
different operating systems, networking stacks, and TLS libraries
(modern Ubuntu build OpenConnect with GnuTLS, not OpenSSL)? they're
pretty hard to avoid.
Dan
