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:-)