OpenVPN with mbed TLS: no warning for unsupported LZO compression — successfully connects without warning but not operable about openvpn HOT 8 OPEN

You are probably hit by an obscure bug that lz4 enabled and lzo disabled does not trigger an error on comp-lzo in the configuration. If both were disabled, OpeNVPN would already error out when seeing comp-lzo in the config.

from openvpn.

Just double checked the code, having comp-lzo in your config should cause a problem:

#ifndef ENABLE_LZO
    if (info->alg == COMP_ALG_LZO)
    {
        msg(msglevel, "OpenVPN is compiled without LZO support. Requested "
            "compression cannot be enabled.");
        return false;
    }
#endif

So unless you are running against an very old OpenVPN Access Server that has setenv FORWARD_COMPATIBLE 1 in the client configurations or someone else who considered doing that a good idea, you should get an error on the client.

Please provide client configuration as well as client log because this error is currently not reproducible.

from openvpn.

mbedtls or OpenSSL has no effect on "supported compression algorithms" - but whoever built your binaries might have chosen to build the mbedtls binary without compression and the OpenSSL "with all".

Normally OpenVPN should be quite clear about unsupported compression settings - but without a log (verb 4) we can't see what is happening, and where it fails.

This all said, don't use compression unless you know you have highly compressible data and that benefit outweighs the known risks. Normal web traffic does not benefit from compression, and there's attacks against browsers that can leverage compression effects inside VPNs (google "VORACLE").

from openvpn.

@cron2
Yes, I agree - it's a security issue and OpenVPN doesn't really decide what's supported and what is not.
However, OpenVPN is responsible for configuration and setup.

I can not change the server settings and thus must deal with a public server using the software's default self-signed certificate and compression. Multiple attempts to call for a change failed so far.

What I did not expect is that the same configuration file used for 10+ years stops working without any error or warning. Furthermore, ping and route tests work, making you go down a rabbit hole.

As OpenVPN reads the configuration file and gets the list of supported compression methods, or even more, it makes sense that OpenVPN gives the waring if the two together don't agree. (My opinion, of course)

Please let me know if there's something I don't see here.

Thanks

Florian

Edit, btw, I did verb 4 on both logs, the working desktop client and the router. And as said before, there was absolutely no difference but timestamps and the line listed above. That's what drove me even more crazy until I finally found it.. and no, it doesn't "fail" anywhere, that's the whole point if this issue

from openvpn.

OpenVPN has warnings about options are pushed and not supported.

And security moves on. Things that were acceptable 10 years ago are no longer. But in your case, you might run into a super obscure corner case bug. Basically nobody disables LZO compression but leaves LZ4 compression on. Typically, you have either no compression at all, only LZO or LZ4+LZO but I never seen only LZ4.

from openvpn.

@schwabe
So you say if I leave out the comp-lzo yes option and the server pushes it, it should generate a warning?

Anyway, the package containing the no LZO yes LZ4 is an official OpenWRT package. So, maybe I should tell them instead!?

from openvpn.

Added "moreinformationneeded" label since we will still need a log of what is actually happening.

from openvpn.

Hi @schwabe
Thanks for the feedback.

So, I poked a bit around the different OpenWRT packages and found a comment sirt of hidden in the client configuration example provided with the package, which states

# Compression is not recommended, as compression and
# encryption in combination can weaken the security
# of the connection.
#
# LZ4 requires OpenVPN 2.4+ on server and client
#option compress lz4
# LZO is available by default only in openvpn-openssl variant

So, it seems by choice.

Give me a moment to setup a clone to reproduce the logs - don't want to mess with my working system right now.

As for the network server, the instance has been upgraded in 2020 or thereabouts, so don't know.
Is there a way to check version or so without access to the interface? I have full access to the net, so to speak - but not this specific server.

from openvpn.