Openvpn setup is fine but not passing traffic anymore

A problem that I did run into after updating on openssl on August 10, Network Manger could set up the openvpn connection without problems but no data was passing through.

To diagnose the problem I did look in the journal and saw:

Bad LZO decompression header byte: 42

Also did already before this notice in the journal:

WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless “allow-compression yes” is also set.

For a few days I was able to work-around the problem by setting changing “comp-lzo=no” to “comp-lzo=yes” in the .ovpn file. Did try that connecting from the command line using:

> sudo openvpn --config my_config_file.opvn

Till yesterday that worked, I did also not see the “Bad LZO decompression” errors anymore. My interpretation of this is that although the .ovpn said “comp-lzo=no” the VPN server did enable LZO compression anyhow. As I got that .ovpn file from the VPN provider I think it is a problem at their side but I saw this problem for two VPN’s I tried.

Today (after an update yesterday) no traffic is passing with comp-lzo=no" to “comp-lzo=yes” on both VPN’s.

I did set up the connection adding “–verb 5” but as soon as the connection is up no outside ping is working anymore. With “–verb 5” the openvpn log is showing

Output R and W characters to the console for each packet read and write, uppercase is used for TCP/UDP packets and lowercase is used for TUN/TAP packets.

And that shows:


And that continues trying to ping so it looks like traffic is passing the VPN tunnel.

No sure what is the problem today, only problem I saw in the verbose log is:

2023-08-13 09:08:26 us=364717 No valid translation found for TLS cipher '@SECLEVEL=0'

That was added because of:

One VPN I use solved that problem but the other indicate it is still on the planning. I do not see this warning if I do not run with “–verb 5” so I do not if this warning is already longer present but I doubt it has to do with the current problem as then there was a clear error “md too weak”.

As I see the problem (no data passing, no errors) for two VPN’s I doubt it is direct related with the VPN provider.

Not sure what changed but later today ovenvpn is forwarding traffic again although still with “comp-lzo=no” changed to “comp-lzo=yes”

Found out yesterday that the remaining problem is with NetworkManager.

If I start the VPN connection from the command line it works without problems.

If I right click the Network icon → Configure Network Connections, press the + button under “Connection” I can choose the Connect Type “Import VPN connection”. If I use there exact same .opvn file I get a new connection but when I try to connect using that the connection get set up but not traffic passing. At the same time I see in the journal I see once more “Bad LZO decompression header byte: 42” so it looks like the Network Manager does not pass the “comp-lzo=no” to openvpn.

“Compress” on OpenVPN (#534) · Issues · NetworkManager / NetworkManager · GitLab

1 Like