Re: [Openvpn-users] migrating from lzo to lz4

[Gert Doering]

Hi,

On Fri, Nov 17, 2017 at 02:04:48PM +0100, Ralf Hildebrandt wrote:
> Now I tried pushing individual compression algorithms to clients,
> testing with my own account:
> 
> if (defined $ENV{'IV_LZ4'} && ($username eq "hildeb") ) {
> $logger->info("$username LZ4 available");
> push @outline, 'push "compress lz4"';

You need to config both sides, push remote and compress local:

 if (defined $ENV{'IV_LZ4'} && ($username eq "hildeb") ) {
 $logger->info("$username LZ4 available");
 push @outline, 'push "compress lz4"', 'compress lz4';

(the server can speak different compression algorithms at a time, but
for reasons lost in the mists of time it needs to be told what to expect
- even though the compression byte is actually telling it)

gert
-- 
now what should I write here...

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Ralf Hildebrandt]

* Jan Just Keijser :

> keep in mind that you also need to tell the server to use LZ4 for your
> client; in my original script I was writing out
>   compress lz4
>   push "compress lz4"
> 
> your server seems "stuck" on "compress lzo".

Working now, yay!

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Jan Just Keijser]

Hi Ralf,

On 17/11/17 14:04, Ralf Hildebrandt wrote:

* David Sommerseth :

On 16/11/17 09:42, Илья Шипицин wrote:

just "compression" is somewhat not clearly covered by documentation. is
it "stub" ? or is it "enable both lzo and lz4" ?

My man page says:

   --compress [algorithm]
[...snip...]

If  the  algorithm  parameter is empty, com‐
pression will be turned off, but the  packet
framing   for   compression  will  still  be
enabled, allowing a different setting to  be
pushed later.

If this is not clear enough, how could we improve that?

But JJK is most likely right that lzo and lz4 cannot be mixed between
clients.  But you can have some clients which gets a 'push "compress
$ALGORITHM", where $ALGORITHM is either lzo or lz4 [1].

Code wise, --comp-lzo yes is the same as --compress lzo.
And --comp-lzo no is the same as just --compress.  But --compress is the
only one allowing different compression algorithms.


[1] Valid values are actually: stub, stub-v2, lzo, lz4, lz4-v2 - but the
various differences seems poorly documented outside the source code.

I tried implementing this; my server config uses:

compress lzo

which is backwards compatible to all my clients which use "comp-lzo".
This works fine.


Now I tried pushing individual compression algorithms to clients,
testing with my own account:

if (defined $ENV{'IV_LZ4'} && ($username eq "hildeb") ) {
 $logger->info("$username LZ4 available");
 push @outline, 'push "compress lz4"';

and that results a major FUBAR:

Nov 17 13:41:59 openvpn udp[23345]: hildeb/10.31.111.66 SENT CONTROL [hildeb]: 
'PUSH_REPLY,dhcp-option DNS 141.42.1.1,dhcp-option DOMAIN
charite.de,sndbuf 393216,rcvbuf 393216,route-gateway 172.29.0.1,topology 
subnet,ping 10,ping-restart 30,route 10.28.0.0
255.254.0.0,route 10.32.0.0 255.224.0.0,route 172.16.0.0 255.254.0.0,route 
192.168.192.0 255.255.192.0,route 141.42.0.0
255.255.0.0,route 193.175.72.0 255.255.255.0,route 193.175.74.0 
255.255.254.0,route 194.94.4.0 255.255.254.0,compress lz4,ifconfig
172.29.0.91 255.255.192.0,peer-id 124,cipher AES-256-GCM' (status=1)
Nov 17 13:41:59 openvpn udp[23345]: hildeb/10.31.111.66 Data Channel: using 
negotiated cipher 'AES-256-GCM'
Nov 17 13:41:59 openvpn udp[23345]: hildeb/10.31.111.66 Outgoing Data Channel: 
Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 17 13:41:59 openvpn udp[23345]: hildeb/10.31.111.66 Incoming Data Channel: 
Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 17 13:42:01 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251
Nov 17 13:42:02 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251
Nov 17 13:42:05 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251
Nov 17 13:42:05 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251
Nov 17 13:42:05 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251

I'm using openvpn for mac (2.4.4)...
keep in mind that you also need to tell the server to use LZ4 for your 
client; in my original script I was writing out

  compress lz4
  push "compress lz4"

your server seems "stuck" on "compress lzo".

HTH,

JJK


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Ralf Hildebrandt]

* David Sommerseth :
> On 16/11/17 09:42, Илья Шипицин wrote:
> > 
> > just "compression" is somewhat not clearly covered by documentation. is
> > it "stub" ? or is it "enable both lzo and lz4" ?
> 
> My man page says:
> 
>   --compress [algorithm]
>[...snip...]
> 
>If  the  algorithm  parameter is empty, com‐
>pression will be turned off, but the  packet
>framing   for   compression  will  still  be
>enabled, allowing a different setting to  be
>pushed later.
> 
> If this is not clear enough, how could we improve that?
> 
> But JJK is most likely right that lzo and lz4 cannot be mixed between
> clients.  But you can have some clients which gets a 'push "compress
> $ALGORITHM", where $ALGORITHM is either lzo or lz4 [1].
> 
> Code wise, --comp-lzo yes is the same as --compress lzo.
> And --comp-lzo no is the same as just --compress.  But --compress is the
> only one allowing different compression algorithms.
> 
> 
> [1] Valid values are actually: stub, stub-v2, lzo, lz4, lz4-v2 - but the
> various differences seems poorly documented outside the source code.

I tried implementing this; my server config uses:

compress lzo

which is backwards compatible to all my clients which use "comp-lzo".
This works fine.


Now I tried pushing individual compression algorithms to clients,
testing with my own account:

if (defined $ENV{'IV_LZ4'} && ($username eq "hildeb") ) {
$logger->info("$username LZ4 available");
push @outline, 'push "compress lz4"';

and that results a major FUBAR:

Nov 17 13:41:59 openvpn udp[23345]: hildeb/10.31.111.66 SENT CONTROL [hildeb]: 
'PUSH_REPLY,dhcp-option DNS 141.42.1.1,dhcp-option DOMAIN
charite.de,sndbuf 393216,rcvbuf 393216,route-gateway 172.29.0.1,topology 
subnet,ping 10,ping-restart 30,route 10.28.0.0
255.254.0.0,route 10.32.0.0 255.224.0.0,route 172.16.0.0 255.254.0.0,route 
192.168.192.0 255.255.192.0,route 141.42.0.0
255.255.0.0,route 193.175.72.0 255.255.255.0,route 193.175.74.0 
255.255.254.0,route 194.94.4.0 255.255.254.0,compress lz4,ifconfig
172.29.0.91 255.255.192.0,peer-id 124,cipher AES-256-GCM' (status=1)
Nov 17 13:41:59 openvpn udp[23345]: hildeb/10.31.111.66 Data Channel: using 
negotiated cipher 'AES-256-GCM'
Nov 17 13:41:59 openvpn udp[23345]: hildeb/10.31.111.66 Outgoing Data Channel: 
Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 17 13:41:59 openvpn udp[23345]: hildeb/10.31.111.66 Incoming Data Channel: 
Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 17 13:42:01 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251
Nov 17 13:42:02 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251
Nov 17 13:42:05 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251
Nov 17 13:42:05 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251
Nov 17 13:42:05 openvpn udp[23345]: hildeb/10.31.111.66 Bad LZO decompression 
header byte: 251

I'm using openvpn for mac (2.4.4)...

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Ralf Hildebrandt]

* Jan Just Keijser :

> This makes a very nice example for a future cookbook :)

I must admin that your cookbook is one of the few IT related book I
often use as reference :)

> You'd use OpenVPN 2.4+ on the server with a client-connect script like this:
> 
> #!/bin/bash
> 
> env | grep IV_
> 
> if [ "${IV_LZ4:-0}" -eq 1 ]
> then
>     echo "Enabling LZ4 compression for client $common_name"
>     echo "compress lz4" > $1
>     echo "push \"compress lz4\"" >> $1
> else
>     echo "Enabling LZO compression for client $common_name"
>     echo "comp-lzo" >> $1
>     echo "push \"comp-lzo\"" >> $1
> fi

Awesome.
I'll try this.

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Jan Just Keijser]

On 16/11/17 11:45, Ralf Hildebrandt wrote:

* Jan Just Keijser :


yes, pretty much: all clients that have 'comp-lzo' in the client config and
that support LZ4 can be told to use LZ4 compression by adding
   push "compress lz4"
in the server config.

I have a mix of Windows (openvpn 2.3 and 2.4)
and Mac (openvpn 2.3 only, I wonder why TunnelBlick shuns 2.4?) clients
out in the field.

So you say, I can simply

push "compress lz4"

to all client (?) and then

a) either the client will accept and use lz4 (2.4 I guess)
b) or the client will fail, ignore the push and use lzo instead?

then I'd put "comp-lzo yes" on all clients (2.3 clients don't recognize 
"compress").

"push-peer-info" will tell you whether a client supports LZ4 or not.

How do I use that?


This makes a very nice example for a future cookbook :)
You'd use OpenVPN 2.4+ on the server with a client-connect script like this:

#!/bin/bash

env | grep IV_

if [ "${IV_LZ4:-0}" -eq 1 ]
then
    echo "Enabling LZ4 compression for client $common_name"
    echo "compress lz4" > $1
    echo "push \"compress lz4\"" >> $1
else
    echo "Enabling LZO compression for client $common_name"
    echo "comp-lzo" >> $1
    echo "push \"comp-lzo\"" >> $1
fi



my server log file shows:

Thu Nov 16 13:53:58 2017 192.168.0.49:55089 [client2] Peer Connection Initiated 
with [AF_INET]192.168.0.49:55089
Thu Nov 16 13:53:58 2017 client2/192.168.0.49:55089 MULTI_sva: pool returned 
IPv4=10.200.0.2, IPv6=2001:610:120::200:0:1001
IV_COMP_STUBv2=1
IV_LZ4v2=1
IV_COMP_STUB=1
IV_LZ4=1
IV_PLAT=linux
IV_PROTO=2
IV_LZO=1
IV_TCPNL=1
IV_NCP=2
IV_VER=2.4.4
Enabling LZ4 compression for client client2
Thu Nov 16 13:54:04 2017 192.168.0.180:43459 peer info: IV_VER=2.3.7
Thu Nov 16 13:54:04 2017 192.168.0.180:43459 peer info: IV_PLAT=linux
Thu Nov 16 13:54:04 2017 192.168.0.180:43459 peer info: IV_PROTO=2
Thu Nov 16 13:54:04 2017 192.168.0.180:43459 [client1] Peer Connection 
Initiated with [AF_INET]192.168.0.180:43459
Thu Nov 16 13:54:04 2017 client1/192.168.0.180:43459 MULTI_sva: pool returned 
IPv4=10.200.0.3, IPv6=2001:610:120::200:0:1002
IV_PLAT=linux
IV_PROTO=2
IV_VER=2.3.7
Enabling LZO compression for client client1


and yes, the server is able to simultaneously use LZO for client1 and LZ4 for 
client2.

HTH,

JJK


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[David Sommerseth]

On 16/11/17 09:42, Илья Шипицин wrote:
> 
> just "compression" is somewhat not clearly covered by documentation. is
> it "stub" ? or is it "enable both lzo and lz4" ?

My man page says:

  --compress [algorithm]
   [...snip...]

   If  the  algorithm  parameter is empty, com‐
   pression will be turned off, but the  packet
   framing   for   compression  will  still  be
   enabled, allowing a different setting to  be
   pushed later.

If this is not clear enough, how could we improve that?

But JJK is most likely right that lzo and lz4 cannot be mixed between
clients.  But you can have some clients which gets a 'push "compress
$ALGORITHM", where $ALGORITHM is either lzo or lz4 [1].

Code wise, --comp-lzo yes is the same as --compress lzo.
And --comp-lzo no is the same as just --compress.  But --compress is the
only one allowing different compression algorithms.


[1] Valid values are actually: stub, stub-v2, lzo, lz4, lz4-v2 - but the
various differences seems poorly documented outside the source code.


-- 
kind regards,

David Sommerseth
OpenVPN, Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Ralf Hildebrandt]

* Jonathan K. Bullard :
> Hi,
> 
> On Thu, Nov 16, 2017 at 5:45 AM, Ralf Hildebrandt
>  wrote:
> > * Jan Just Keijser :
> >
> >> yes, pretty much: all clients that have 'comp-lzo' in the client config and
> >> that support LZ4 can be told to use LZ4 compression by adding
> >>   push "compress lz4"
> >> in the server config.
> >
> > I have a mix of Windows (openvpn 2.3 and 2.4)
> > and Mac (openvpn 2.3 only, I wonder why TunnelBlick shuns 2.4?) clients
> > out in the field.
> 
> Can you expand on that?

Of course:
# zcat -f /var/log/daemon.log* | awk '/IV_VER=/ {printf("%s ",$NF);next;} 
/IV_PLAT=/ {print $NF;}'  |sort | uniq -c  | sort -n |fgrep mac

  1 IV_VER=2.3.8 IV_PLAT=mac
  1 IV_VER=2.3_git_ec0c1dc IV_PLAT=mac
  1 IV_VER=2.5_git_974513e IV_PLAT=mac
  3 IV_VER=2.3.7 IV_PLAT=mac
  5 IV_VER=2.3.2 IV_PLAT=mac
  8 IV_VER=2.3_git_bae1ad7 IV_PLAT=mac
* 9 IV_VER=2.4_beta1 IV_PLAT=mac
*14 IV_VER=2.4.1 IV_PLAT=mac
*20 IV_VER=2.4.0 IV_PLAT=mac
 38 IV_VER=2.3_git_6a4edc7 IV_PLAT=mac
*42 IV_VER=2.4.3 IV_PLAT=mac
 45 IV_VER=2.3.4 IV_PLAT=mac
*64 IV_VER=2.4.2 IV_PLAT=mac
144 IV_VER=2.3.16 IV_PLAT=mac
*   170 IV_VER=2.4.4 IV_PLAT=mac
173 IV_VER=2.3.15 IV_PLAT=mac
193 IV_VER=2.3.10 IV_PLAT=mac
218 IV_VER=2.3.11 IV_PLAT=mac
387 IV_VER=2.3.12 IV_PLAT=mac
416 IV_VER=2.3.14 IV_PLAT=mac
832 IV_VER=2.3.17 IV_PLAT=mac
898 IV_VER=2.3.6 IV_PLAT=mac
   4853 IV_VER=2.3.18 IV_PLAT=mac

> Tunnelblick has included various versions of OpenVPN 2.4 (along with
> 2.3) for a long time, starting with a Tunnelblick release a year ago
> tomorrow that included OpenVPN 2.4.0_beta1. The current version
> (Tunnelblick 3.7.4a) includes OpenVPN 2.4.4 and OpenVPN 2.3.18.

But it seems that 2.3.x is the default, judging by the numbers of my
tech-agnostic users. I very much like tunneblick's update strategy;
there's nothing worse than the average windows user who tries to
connect using window10 and openvpn 2.3.4 :/
 
-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Илья Шипицин]

2017-11-16 15:39 GMT+05:00 Jan Just Keijser :

> Hi,
>
>
> On 16/11/17 11:29, Илья Шипицин wrote:
>
>
>
> 2017-11-16 15:21 GMT+05:00 Jan Just Keijser :
>
>> Hi,
>>
>>
>> On 16/11/17 09:42, Илья Шипицин wrote:
>>
>>
>>
>> 2017-11-16 13:35 GMT+05:00 David Sommerseth <
>> open...@sf.lists.topphemmelig.net>:
>>
>>> On 16/11/17 06:59, Илья Шипицин wrote:
>>> > hi,
>>> >
>>> > I'm running vpn server since 2012, with comp-lzo enabled (on both
>>> client
>>> > and server side)
>>> >
>>> > in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
>>> >
>>> > also, I'm considering switching to lz4 from lzo.
>>> >
>>> > any best practice how to switch lzo --> lz4 without operation
>>> interruption ?
>>>
>>> First of all, I'd recommend you to do some performance testing on the
>>> typical payload you're pushing through your tunnel.  You might find that
>>> LZO can perform better than LZ4 in some scenarios with a lower CPU load.
>>>  But it is hard to come with a generic recommendation; it depends a lot
>>> on what you push through your tunnel and how compressible that data
>>> stream is.  A bit more info can be found here: <
>>> https://github.com/lz4/lz4/>
>>>
>>> Another detail is the security aspects related to compressing data
>>> streams.  The CRIME attack [0] is now an ageing side-channel attack
>>> vector which is made possible due to compression.  And there are other
>>> compression oracle attacks [1] too, like BREACH [2].
>>>
>>> [0] 
>>> [1] 
>>> [2]
>>> >> ps-secrets-in-under-30-seconds/101579/>
>>>
>>> --compress is pushable.  Not sure if you can mix lzo and lz4
>>>
>>
>> it is a separate question, why pushing must be enabled (and it is not
>> enabled by default).
>>
>> this is mostly due to historical reasons: if you enable any form of
>> compression, one byte is reserved in each packet for a possible compression
>> flag. Thus, for incompressible data, it actually *hurts* performance to
>> enable compression.
>>
>>
>> however, I address here another question, are lzo and lz4 mutually
>> exclusive ?
>>
>> yes, they are: you can only specify one type of compression per server.
>>
>>
>> according to man page, you must explicitely specify either "compression
>> lzo" or "compression lz4".
>>
>>
>>> compression, but I'd just add 'compression' in all the config files and
>>>
>>
>> just "compression" is somewhat not clearly covered by documentation. is
>> it "stub" ? or is it "enable both lzo and lz4" ?
>>
>>
>>> then only push 'compress {lzo,lz4}' to those clients that is reasonable
>>> to use.  I would not, however, enable compression itself on by default -
>>> just have the compression framing available.
>>>
>>>
>> by adding
>>   compression
>> or
>>   comp-lzo
>> to the client config, you turn on the compression bit in each packet, and
>> thus allow the server to push the compression algorithm of choice to all
>> clients.
>>
>
> so, if clients support pushes (2.3 or higher), I can leave "comp-lzo" in
> client configs  enable "compress lz4" in server configs and push it ?
> those clients who do not support pushes will get broken ?
>
>
> yes, pretty much: all clients that have 'comp-lzo' in the client config
> and that support LZ4 can be told to use LZ4 compression by adding
>   push "compress lz4"
> in the server config.
> "push-peer-info" will tell you whether a client supports LZ4 or not.
>

I missed that, thank you!
we already put all clients IV_xxx variables to log. I can check all clients.



>
> JJK
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Jonathan K. Bullard]

Hi,

On Thu, Nov 16, 2017 at 5:45 AM, Ralf Hildebrandt
 wrote:
> * Jan Just Keijser :
>
>> yes, pretty much: all clients that have 'comp-lzo' in the client config and
>> that support LZ4 can be told to use LZ4 compression by adding
>>   push "compress lz4"
>> in the server config.
>
> I have a mix of Windows (openvpn 2.3 and 2.4)
> and Mac (openvpn 2.3 only, I wonder why TunnelBlick shuns 2.4?) clients
> out in the field.

Can you expand on that?

Tunnelblick has included various versions of OpenVPN 2.4 (along with
2.3) for a long time, starting with a Tunnelblick release a year ago
tomorrow that included OpenVPN 2.4.0_beta1. The current version
(Tunnelblick 3.7.4a) includes OpenVPN 2.4.4 and OpenVPN 2.3.18.

Tunnelblick beta versions often also include a version of OpenVPN
built from the master branch when there are significant commits since
the last OpenVPN release. (The current beta doesn't include one
because I haven't seen much in the way of commits since 2.4.4 was
released.)

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Ralf Hildebrandt]

* Jan Just Keijser :

> by adding
>   compression

compress

> or
>   comp-lzo
> to the client config, you turn on the compression bit in each packet, and
> thus allow the server to push the compression algorithm of choice to all
> clients.

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Ralf Hildebrandt]

* Jan Just Keijser :

> yes, pretty much: all clients that have 'comp-lzo' in the client config and
> that support LZ4 can be told to use LZ4 compression by adding
>   push "compress lz4"
> in the server config.

I have a mix of Windows (openvpn 2.3 and 2.4)
and Mac (openvpn 2.3 only, I wonder why TunnelBlick shuns 2.4?) clients
out in the field.

So you say, I can simply 

push "compress lz4"

to all client (?) and then

a) either the client will accept and use lz4 (2.4 I guess)
b) or the client will fail, ignore the push and use lzo instead?

> "push-peer-info" will tell you whether a client supports LZ4 or not.

How do I use that?

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Jan Just Keijser]

Hi,

On 16/11/17 11:29, Илья Шипицин wrote:



2017-11-16 15:21 GMT+05:00 Jan Just Keijser mailto:janj...@nikhef.nl>>:

Hi,


On 16/11/17 09:42, Илья Шипицин wrote:



2017-11-16 13:35 GMT+05:00 David Sommerseth mailto:open...@sf.lists.topphemmelig.net>>:

On 16/11/17 06:59, Илья Шипицин wrote:
> hi,
>
> I'm running vpn server since 2012, with comp-lzo enabled (on both 
client
> and server side)
>
> in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
>
> also, I'm considering switching to lz4 from lzo.
>
> any best practice how to switch lzo --> lz4 without operation 
interruption ?

First of all, I'd recommend you to do some performance testing on the
typical payload you're pushing through your tunnel.  You might find that
LZO can perform better than LZ4 in some scenarios with a lower CPU load.
 But it is hard to come with a generic recommendation; it depends a lot
on what you push through your tunnel and how compressible that data
stream is.  A bit more info can be found here: 


Another detail is the security aspects related to compressing data
streams.  The CRIME attack [0] is now an ageing side-channel attack
vector which is made possible due to compression.  And there are other
compression oracle attacks [1] too, like BREACH [2].

[0] >
[1] >
[2]

>

--compress is pushable.  Not sure if you can mix lzo and lz4


it is a separate question, why pushing must be enabled (and it is not 
enabled by default).


this is mostly due to historical reasons: if you enable any form of 
compression, one byte is reserved in each packet for a
possible compression flag. Thus, for incompressible data, it actually 
*hurts* performance to enable compression.



however, I address here another question, are lzo and lz4 mutually 
exclusive ?

yes, they are: you can only specify one type of compression per server.


according to man page, you must explicitely specify either "compression lzo" or 
"compression lz4".

compression, but I'd just add 'compression' in all the config files and


just "compression" is somewhat not clearly covered by documentation. is it "stub" ? 
or is it "enable both lzo and lz4" ?

then only push 'compress {lzo,lz4}' to those clients that is reasonable
to use.  I would not, however, enable compression itself on by default -
just have the compression framing available.



by adding
  compression
or
  comp-lzo
to the client config, you turn on the compression bit in each packet, and 
thus allow the server to push the compression
algorithm of choice to all clients.


so, if clients support pushes (2.3 or higher), I can leave "comp-lzo" in client configs  enable "compress lz4" in server 
configs and push it ?

those clients who do not support pushes will get broken ?

yes, pretty much: all clients that have 'comp-lzo' in the client config and that support LZ4 can be told to use LZ4 compression 
by adding

  push "compress lz4"
in the server config.
"push-peer-info" will tell you whether a client supports LZ4 or not.

JJK
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Илья Шипицин]

2017-11-16 15:21 GMT+05:00 Jan Just Keijser :

> Hi,
>
>
> On 16/11/17 09:42, Илья Шипицин wrote:
>
>
>
> 2017-11-16 13:35 GMT+05:00 David Sommerseth  topphemmelig.net>:
>
>> On 16/11/17 06:59, Илья Шипицин wrote:
>> > hi,
>> >
>> > I'm running vpn server since 2012, with comp-lzo enabled (on both client
>> > and server side)
>> >
>> > in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
>> >
>> > also, I'm considering switching to lz4 from lzo.
>> >
>> > any best practice how to switch lzo --> lz4 without operation
>> interruption ?
>>
>> First of all, I'd recommend you to do some performance testing on the
>> typical payload you're pushing through your tunnel.  You might find that
>> LZO can perform better than LZ4 in some scenarios with a lower CPU load.
>>  But it is hard to come with a generic recommendation; it depends a lot
>> on what you push through your tunnel and how compressible that data
>> stream is.  A bit more info can be found here: <
>> https://github.com/lz4/lz4/>
>>
>> Another detail is the security aspects related to compressing data
>> streams.  The CRIME attack [0] is now an ageing side-channel attack
>> vector which is made possible due to compression.  And there are other
>> compression oracle attacks [1] too, like BREACH [2].
>>
>> [0] 
>> [1] 
>> [2]
>> > https-secrets-in-under-30-seconds/101579/>
>>
>> --compress is pushable.  Not sure if you can mix lzo and lz4
>>
>
> it is a separate question, why pushing must be enabled (and it is not
> enabled by default).
>
> this is mostly due to historical reasons: if you enable any form of
> compression, one byte is reserved in each packet for a possible compression
> flag. Thus, for incompressible data, it actually *hurts* performance to
> enable compression.
>
>
> however, I address here another question, are lzo and lz4 mutually
> exclusive ?
>
> yes, they are: you can only specify one type of compression per server.
>
>
> according to man page, you must explicitely specify either "compression
> lzo" or "compression lz4".
>
>
>> compression, but I'd just add 'compression' in all the config files and
>>
>
> just "compression" is somewhat not clearly covered by documentation. is it
> "stub" ? or is it "enable both lzo and lz4" ?
>
>
>> then only push 'compress {lzo,lz4}' to those clients that is reasonable
>> to use.  I would not, however, enable compression itself on by default -
>> just have the compression framing available.
>>
>>
> by adding
>   compression
> or
>   comp-lzo
> to the client config, you turn on the compression bit in each packet, and
> thus allow the server to push the compression algorithm of choice to all
> clients.
>

so, if clients support pushes (2.3 or higher), I can leave "comp-lzo" in
client configs  enable "compress lz4" in server configs and push it ?
those clients who do not support pushes will get broken ?


>
>
> HTH,
>
> JJK
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Jan Just Keijser]

Hi,

On 16/11/17 09:42, Илья Шипицин wrote:



2017-11-16 13:35 GMT+05:00 David Sommerseth mailto:open...@sf.lists.topphemmelig.net>>:

On 16/11/17 06:59, Илья Шипицин wrote:
> hi,
>
> I'm running vpn server since 2012, with comp-lzo enabled (on both client
> and server side)
>
> in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
>
> also, I'm considering switching to lz4 from lzo.
>
> any best practice how to switch lzo --> lz4 without operation 
interruption ?

First of all, I'd recommend you to do some performance testing on the
typical payload you're pushing through your tunnel.  You might find that
LZO can perform better than LZ4 in some scenarios with a lower CPU load.
 But it is hard to come with a generic recommendation; it depends a lot
on what you push through your tunnel and how compressible that data
stream is.  A bit more info can be found here: 

Another detail is the security aspects related to compressing data
streams.  The CRIME attack [0] is now an ageing side-channel attack
vector which is made possible due to compression.  And there are other
compression oracle attacks [1] too, like BREACH [2].

[0] >
[1] >
[2]

>

--compress is pushable.  Not sure if you can mix lzo and lz4


it is a separate question, why pushing must be enabled (and it is not enabled 
by default).

this is mostly due to historical reasons: if you enable any form of compression, one byte is reserved in each packet for a 
possible compression flag. Thus, for incompressible data, it actually *hurts* performance to enable compression.




however, I address here another question, are lzo and lz4 mutually exclusive ?

yes, they are: you can only specify one type of compression per server.


according to man page, you must explicitely specify either "compression lzo" or 
"compression lz4".

compression, but I'd just add 'compression' in all the config files and


just "compression" is somewhat not clearly covered by documentation. is it "stub" ? or is 
it "enable both lzo and lz4" ?

then only push 'compress {lzo,lz4}' to those clients that is reasonable
to use.  I would not, however, enable compression itself on by default -
just have the compression framing available.



by adding
  compression
or
  comp-lzo
to the client config, you turn on the compression bit in each packet, and thus allow the server to push the compression 
algorithm of choice to all clients.


HTH,

JJK


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[Илья Шипицин]

2017-11-16 13:35 GMT+05:00 David Sommerseth <
open...@sf.lists.topphemmelig.net>:

> On 16/11/17 06:59, Илья Шипицин wrote:
> > hi,
> >
> > I'm running vpn server since 2012, with comp-lzo enabled (on both client
> > and server side)
> >
> > in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
> >
> > also, I'm considering switching to lz4 from lzo.
> >
> > any best practice how to switch lzo --> lz4 without operation
> interruption ?
>
> First of all, I'd recommend you to do some performance testing on the
> typical payload you're pushing through your tunnel.  You might find that
> LZO can perform better than LZ4 in some scenarios with a lower CPU load.
>  But it is hard to come with a generic recommendation; it depends a lot
> on what you push through your tunnel and how compressible that data
> stream is.  A bit more info can be found here: <
> https://github.com/lz4/lz4/>
>
> Another detail is the security aspects related to compressing data
> streams.  The CRIME attack [0] is now an ageing side-channel attack
> vector which is made possible due to compression.  And there are other
> compression oracle attacks [1] too, like BREACH [2].
>
> [0] 
> [1] 
> [2]
>  steals-https-secrets-in-under-30-seconds/101579/>
>
> --compress is pushable.  Not sure if you can mix lzo and lz4
>

it is a separate question, why pushing must be enabled (and it is not
enabled by default).


however, I address here another question, are lzo and lz4 mutually
exclusive ?

according to man page, you must explicitely specify either "compression
lzo" or "compression lz4".


> compression, but I'd just add 'compression' in all the config files and
>

just "compression" is somewhat not clearly covered by documentation. is it
"stub" ? or is it "enable both lzo and lz4" ?


> then only push 'compress {lzo,lz4}' to those clients that is reasonable
> to use.  I would not, however, enable compression itself on by default -
> just have the compression framing available.
>
>
> --
> kind regards,
>
> David Sommerseth
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] migrating from lzo to lz4

[David Sommerseth]

On 16/11/17 06:59, Илья Шипицин wrote:
> hi,
> 
> I'm running vpn server since 2012, with comp-lzo enabled (on both client
> and server side)
> 
> in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
> 
> also, I'm considering switching to lz4 from lzo.
> 
> any best practice how to switch lzo --> lz4 without operation interruption ?

First of all, I'd recommend you to do some performance testing on the
typical payload you're pushing through your tunnel.  You might find that
LZO can perform better than LZ4 in some scenarios with a lower CPU load.
 But it is hard to come with a generic recommendation; it depends a lot
on what you push through your tunnel and how compressible that data
stream is.  A bit more info can be found here: 

Another detail is the security aspects related to compressing data
streams.  The CRIME attack [0] is now an ageing side-channel attack
vector which is made possible due to compression.  And there are other
compression oracle attacks [1] too, like BREACH [2].

[0] 
[1] 
[2]


--compress is pushable.  Not sure if you can mix lzo and lz4
compression, but I'd just add 'compression' in all the config files and
then only push 'compress {lzo,lz4}' to those clients that is reasonable
to use.  I would not, however, enable compression itself on by default -
just have the compression framing available.


--
kind regards,

David Sommerseth



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] migrating from lzo to lz4

[Илья Шипицин]

hi,

I'm running vpn server since 2012, with comp-lzo enabled (on both client
and server side)

in openvpn-2.4 comp-lzo is deprecated in favor of compress option.

also, I'm considering switching to lz4 from lzo.

any best practice how to switch lzo --> lz4 without operation interruption ?


Cheers,
Ilya Shipitsin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users