On 1 August 2018 at 11:41, Jeroen Balduyck <jeroen.balduyck at gmail.com> wrote: > On 31 July 2018 at 23:54, Daniel Lenski <dlenski at gmail.com> wrote: >> On Tue, Jul 31, 2018 at 5:32 AM, Jeroen Balduyck >> <jeroen.balduyck at gmail.com> wrote: >>> On Opnsense (Freebsd) I'm running Openconnect in client mode. I get >>> this unusual error: >>> >>> LZS decompression failed: File too large. >> >> openconnect --compression=none should provide an immediate workaround, >> by disabling compression of tunneled packets. >> >> It looks like you're connecting to an ocserv server. Can you include >> the full output of openconnect --version, ocserv --version, including >> the libraries? >> >> Dan > > Hi Daniel, > > I have already tried -D,--no-deflate but that highly impacted the > throughput (went from 70 Mbps to 10-ish Mbps). I'll try with > --compression=none. Not sure what the difference between those 2 is? > > Anyway, here is the version information: > > Version info on the Opnsense box: > ----------------------------------------------- > openconnect --version > OpenConnect version v7.08-unknown > Using OpenSSL. Features present: TPM (OpenSSL ENGINE not present), > HOTP software token, TOTP software token, DTLS > > > I'm sorry but I'm not sure about what you meant by 'including > libraries'. So I guessed you want the version of the OpenSSL-library? > > openssl version -a > OpenSSL 1.0.2k-freebsd 26 Jan 2017 > built on: date not available > platform: FreeBSD-amd64 > options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) > compiler: clang > OPENSSLDIR: "/etc/ssl" > > Version info on ocserv server: > ------------------------------------------ > Pending request. I know they are running 0.11.9 but they don't seem to > forthcoming on giving me more info:-) > > Some other remarks: > --------------------------- > > 1) On my Macbook Pro the negotiated encr. algo is AES-256-GCM. On > Opnsense it is AES256-CBC-SHA. Not sure why as the Opnsense box also > supports the GCM-cipher. But that is probably just a setting somewhere > or a difference in the TLS cipher negotiation. I do know the server > prefers the GCM-ciphers as it is in the online documentation. Still, > it appears strange to me the GCM cipher is not being selected? > 2) On the Macbook GnuTLS is used instead of OpenSSL > 3) Version info lacks "-unknown" suffix on the Macbook 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. The negotiation works fine on Ubuntu and MacOS but not on Opnsense or maybe even on FreeBSD in general. [speculating]So we might be looking at BSD specific code that is causing this bug? This is how it looks like: tun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1322 Also as I said earlier, I don't get why it defaults to AES256-CBC-SHA but I'll do some TCP dumping pretty soon to find out what is being advertised on the Opnsense side as available ciphers. Now I'll just let the smarter people fix this:-)
