Re: [Openvpn-devel] [PATCH] Make '--comp-lzo no' the default behaviour if LZO is enabled

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/05/11 11:55, Jan Just Keijser wrote:
>> - From a quick brain storm, for --comp-lzo, the only compatible/valid
>> combinations are:
>>
>>Client  Server
>>(no --comp-lzo) (no --comp-lzo)
>>--comp-lzo {,adaptive} (*)  --comp-lzo {,adaptive}
>>--comp-lzo yes (*)  --comp-lzo yes
>>--comp-lzo no  (*)  --comp-lzo no
>>
>> (*) In these combinations, comp-lzo should be pushable which can change the
>> client setting.  If client does not have comp-lzo in its config, it should
>> disconnect from the server if the server pushes --comp-lzo settings, as the
>> wire protocol from the server will be different from what the client
>> expects.
>>
>>   
> please remember the reason for this patch: bug
>  https://community.openvpn.net/openvpn/ticket/128
> 
> if there is a 'comp-lzo' mismatch and the server pushes out 'push "comp-lzo
> yes"' then upon reconnecting it works all of a sudden - this inconsistency
> needs to be addressed one way or the other.
> If we don't want to change the 'comp-lzo' behaviour then at the very least
> this "reconnect-makes-it-work" feature/bug should be fixed in a different
> manner.

Hi Jan,

Yeah, that is the reason why I think a disconnect should happen when the
client is not using comp-lzo (no --comp-lzo defined), while the server
pushes it.  This is a misconfiguration to start with.  However, when the
client disconnects and stops running, it should give a sensible error
message - to help solve this issue.

Why it "works" with a reconnect, is that the first connect fails because
client config is not using --comp-lzo.  But the server managed to get a
- --comp-lzo push through, which then enables it on the client on the next
reconnect.  This is actually a the real misbehaviour, and is a bug.

When this bug is fixed, we can consider an "auto-fix feature", where it
will reconnect with '--comp-lzo no' in this kind of situation, without
giving odd errors in the log files.  This auto-fix feature should probably
be possible to disable, for those wanting more control over what's happening.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk3WQjAACgkQDC186MBRfroqZQCeOMiuIGsYgze9omfQpjiL9Zfg
6IQAn1ffLU1b1LV9a5nhmuWCWm4XCoKH
=dILR
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] Make '--comp-lzo no' the default behaviour if LZO is enabled

[Jan Just Keijser]

Hi *,

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/05/11 13:10, David Sommerseth wrote:
  

This makes 'comp-lzo' pushable without requiring clients to have
--comp-lzo defined in the client configs.  To make 'comp-lzo' not
pushable on the client, a new 'disabled' argument have been added.

Trac-ticket: 128
Signed-off-by: David Sommerseth 
---
 openvpn.8 |   12 ++--
 options.c |   10 +++---
 2 files changed, 13 insertions(+), 9 deletions(-)




As announced on the developers meeting yesterday (Samuli will paste the
summary with the discussion), I'm withdrawing this patch in the current form.

The reason is that the OpenVPN wire protocol changes slightly when using
'--comp-lzo no' versus not having --comp-lzo in the config file.  This
change will cause server/client incompatibilities.

Alon proposed another approach with white/blacklist of pushed options which
should be processed.  And this approach do make a lot of sense, and we
should implement this as well.  But this will be a bigger change.

However, I'm looking at a different approach right now isolated to
- --comp-lzo, where OpenVPN can detect incompatible --comp-lzo settings and
rather provide a better error and stop OpenVPN.  This I consider better
than to try to reconnect indefinitely when critical config options on
client and server is incompatible.

- From a quick brain storm, for --comp-lzo, the only compatible/valid
combinations are:

   Client  Server
   (no --comp-lzo) (no --comp-lzo)
   --comp-lzo {,adaptive} (*)  --comp-lzo {,adaptive}
   --comp-lzo yes (*)  --comp-lzo yes
   --comp-lzo no  (*)  --comp-lzo no

(*) In these combinations, comp-lzo should be pushable which can change the
client setting.  If client does not have comp-lzo in its config, it should
disconnect from the server if the server pushes --comp-lzo settings, as the
wire protocol from the server will be different from what the client expects.

  

please remember the reason for this patch: bug
 https://community.openvpn.net/openvpn/ticket/128

if there is a 'comp-lzo' mismatch and the server pushes out 'push 
"comp-lzo yes"' then upon reconnecting it works all of a sudden - this 
inconsistency needs to be addressed one way or the other.
If we don't want to change the 'comp-lzo' behaviour then at the very 
least this "reconnect-makes-it-work" feature/bug should be fixed in a 
different manner.


JM2CW,

JJK

Re: [Openvpn-devel] [PATCH] Make '--comp-lzo no' the default behaviour if LZO is enabled

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/05/11 13:10, David Sommerseth wrote:
> This makes 'comp-lzo' pushable without requiring clients to have
> --comp-lzo defined in the client configs.  To make 'comp-lzo' not
> pushable on the client, a new 'disabled' argument have been added.
> 
> Trac-ticket: 128
> Signed-off-by: David Sommerseth 
> ---
>  openvpn.8 |   12 ++--
>  options.c |   10 +++---
>  2 files changed, 13 insertions(+), 9 deletions(-)
> 

As announced on the developers meeting yesterday (Samuli will paste the
summary with the discussion), I'm withdrawing this patch in the current form.

The reason is that the OpenVPN wire protocol changes slightly when using
'--comp-lzo no' versus not having --comp-lzo in the config file.  This
change will cause server/client incompatibilities.

Alon proposed another approach with white/blacklist of pushed options which
should be processed.  And this approach do make a lot of sense, and we
should implement this as well.  But this will be a bigger change.

However, I'm looking at a different approach right now isolated to
- --comp-lzo, where OpenVPN can detect incompatible --comp-lzo settings and
rather provide a better error and stop OpenVPN.  This I consider better
than to try to reconnect indefinitely when critical config options on
client and server is incompatible.

- From a quick brain storm, for --comp-lzo, the only compatible/valid
combinations are:

   Client  Server
   (no --comp-lzo) (no --comp-lzo)
   --comp-lzo {,adaptive} (*)  --comp-lzo {,adaptive}
   --comp-lzo yes (*)  --comp-lzo yes
   --comp-lzo no  (*)  --comp-lzo no

(*) In these combinations, comp-lzo should be pushable which can change the
client setting.  If client does not have comp-lzo in its config, it should
disconnect from the server if the server pushes --comp-lzo settings, as the
wire protocol from the server will be different from what the client expects.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk3WOJ4ACgkQDC186MBRfrq8/gCfYJz7aoPQwNrSTIaz9letMTTC
ufsAnR7MdJtsZz6wvRyJOxCwKOU3tZcs
=SaAA
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] Add parameter "dev " to add_route and delete_route for IPv4, as it is done for IPv6.

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/05/11 10:33, Xavier Franquet wrote:
> When openvpn tries to add (or delete) an IPv4 route, doesn't use the 
> parameter "dev " in the command.
> If there's a local subnet that matches the VPN Server network, the route 
> would use a wrong interface.
> Ex:
>local subnet 10.100.0.0/24 on iface eth2
>openvpn pool 10.100.0.0/16 on iface tap2 (ifconfig_pool_remote_ip is 
> 10.100.0.1)
>   push "route 10.10.0.1 255.255.255.255"
> 
>Without the patch, the route will be added with eth2, instead of tap2
> 
> Signed-off-by: Xavier Franquet 
> ---
>  route.c |   23 +++
>  1 files changed, 15 insertions(+), 8 deletions(-)

Thanks a lot for a better explanation and resending the patch.  At first
glance this makes sense.  But it will break some features in OpenVPN.

- From the man page for --route:

   --route network/IP [netmask] [gateway] [metric]
[...snip...]

  gateway default -- taken from --route-gateway  or  the
  second parameter to --ifconfig when --dev tun is spec‐
  ified.

  metric default -- taken from --route-metric  otherwise
  0.

  The  default  can  be  specified  by leaving an option
  blank or setting it to "default".

  The network and gateway parameters can also be  speci‐
  fied  as  a DNS or /etc/hosts file resolvable name, or
  as one of three special keywords:

  vpn_gateway  --  The  remote  VPN   endpoint   address
  (derived  either  from  --route-gateway  or the second
  parameter to --ifconfig when --dev tun is specified).

  net_gateway -- The pre-existing  IP  default  gateway,
  read  from  the  routing  table  (not supported on all
  OSes).

  remote_host -- The  --remote  address  if  OpenVPN  is
  being  run  in client mode, and is undefined in server
  mode.

As you can see, the [gateway] part of the --route statement can also have
the keywords 'vpn_gateway', 'net_gateway' or 'remote_host'.  Your patch in
the current shape will break this feature.

Gert and I have discussed your patch, and we believe a more appropriate
patch would consider the 'vpn_gateway' keyword.  So if the gateway the new
route will use matches with what 'vpn_gateway' expands to, then adding a
'dev' argument to route makes sense.

What do you think?


kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk3WNN0ACgkQDC186MBRfrqbPACfbnziB9jPepFiVfYlRI7hIsFi
cAwAn0ClniBDn6HY1oV1JIms5TWIBmtO
=Oy1c
-END PGP SIGNATURE-