OpenVPN with mbed TLS: no warning for unsupported LZO compression — successfully connects without warning but not operable

[flhofer]

I tried the past days making a VPN connection work on a router using the same ovpn file and credentials which worked on the laptop. I tried to check all log outputs at high verbosity but could not figure out what it was, until I saw this:

Router :

OpenVPN 2.5.8 aarch64-openwrt-linux-gnu [SSL (mbed TLS)] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]

while the laptop says

OpenVPN 2.5.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD]

There were no other differences comparing the logs with verb 4 and no warnings regarding data compression or delivery.

I would like to receive a warning, if not an error, when a compression type is not supported, especially if I explicitly set comp-lzo yes instead of compress.

System

• OS: openwrt 23.05
• OpenVPN version: 2.5.8

The problem is hard to detect as small packets happen to be correctly routed and delivered. E.g., a ping works just fine even to routed subnets on the deep end of the server's network. I only noticed that there is something wrong with the payload, as the max transmittable packet size differs on terminals but remains constant in time. For example, on the router no ping with payload greater than 71 byes was ever answered, while on a pc in its LAN the maximum was 297 bytes.

Once I replaced the binary with the OpenSSL-build version, the connection worked right away with all the initial settings from the ovpn file.

Thank you.

[cron2]

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").

[flhofer]

@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

[schwabe]

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.

[flhofer]

@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!?

[schwabe]

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.

[flichtenheld]

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

[schwabe]

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.

[flhofer]

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.