comp-lzo (LZO-Adaptive) deprecated in OpenVPN 2.4 and removed in OpenVPN 2.5

[Xentrk]

Just a heads up. I configured OpenVPN server using LZO-Adaptive. I was configuring Tunnelblick on my wife's Mac this morning and got this message.

From the OpenVPN Man Page
--comp-lzo [mode]
DEPRECATED This option will be removed in a future OpenVPN release. Use the newer --compress instead.

LZO and LZ4 are different compression algorithms, with LZ4 generally offering the best performance with least CPU usage. For backwards compatibility with OpenVPN versions before v2.4, use "lzo" (which is identical to the older option "--comp-lzo yes").

 

[RMerlin]

Personally I recommend not using any compression. Most of today's data is either already compressed (audio/video/images), or encrypted (encrypted data is highly random and therefore poorly compressible), so you won't gain much by enabling compression.

 

[Xentrk]

Thanks @RMerlin. I used to not use encryption on the OpenVPN Server. But a few releases ago, I had issues. Enabling compression fixed it.

Likewise, I used to use No Encryption with TorGuard on the client side. Something changed and it stopped working. I'd have to go back to look at some posts I made to find the timeline. I had to then configure my OpenVPN client to use

I will test these settings again with the 384.4 release to see if these items still occur and let you know what I find out.

 

[sfx2000]

Personally I recommend not using any compression. Most of today's data is either already compressed (audio/video/images), or encrypted (encrypted data is highly random and therefore poorly compressible), so you won't gain much by enabling compression.

It can - esp. when using UDP as the transport.

 

[Datalink]

It can - esp. when using UDP as the transport.

Using a Puma 6 modem by any chance? If so, then you probably don't want to use UDP for data transfer due to the UDP losses thru the modem itself.

 

[sfx2000]

Using a Puma 6 modem by any chance? If so, then you probably don't want to use UDP for data transfer due to the UDP losses thru the modem itself.

Puma 6 modems are not very common, and those who have them generally know...

That being said - there are many advantages to using UDP with OpenVPN, just understand the caveats...

 

[RMerlin]

Puma 6 modems are not very common, and those who have them generally know...

That being said - there are many advantages to using UDP with OpenVPN, just understand the caveats...

A colleague once told me that VoIP had serious issues if going through a TCP-based OpenVPN tunnel, but was fine over UDP.

It can - esp. when using UDP as the transport.

Why would it make a difference? I'd actually expect UDP to be even less compressible, since it carries less overhead than TCP.

 

[maxbraketorque]

...

Why would it make a difference? I'd actually expect UDP to be even less compressible, since it carries less overhead than TCP.

@sfx2000, I'd like to hear the answer to this as well.

 

[sfx2000]

@sfx2000, I'd like to hear the answer to this as well.

TCP over TCP is twice the overhead....

Using UDP as the bearer reduces that overhead quite a bit, and one can use larger MTU sizes as well.

 

[maxbraketorque]

TCP over TCP is twice the overhead....

Using UDP as the bearer reduces that overhead quite a bit, and one can use larger MTU sizes as well.

Ah, I thought that you were suggesting that compression had value when using UDP. I guess not?

 

[sfx2000]

Ah, I thought that you were suggesting that compression had value when using UDP. I guess not?

There's still some value to compression - but at a small tradeoff of latency - depends on what traffic is moving over the pipe - video streams for example already have a high amount of compression already.

I suggest to play with it and see what works best...