On 1 August 2018 at 16:23, Daniel Lenski <dlenski at gmail.com> wrote:
> 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
I wish I knew how to do this on *BSD. I *probably* could pull it off
on Linux (giving enough patience).
Any chance you could talk me through? If not I'm still going to try
but don't hold your breath haha:-)
