On Wed, Aug 1, 2018 at 9:46 AM, Jeroen Balduyck
<jeroen.balduyck at gmail.com> wrote:
> 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:-)
I have no personal experience building openconnect on *BSD. Your best
bet is to follow the generic build instructions:
http://www.infradead.org/openconnect/building.html
? and maybe look at the Freshports page which has some details of the
FreeBSD build deps:
https://www.freshports.org/security/openconnect/
Dan
