I have an OpenVPN server with about 300 existing clients, running a mixture of Linux, Mac OS X, iOS, Android, and Windows. Because all of these clients are using "comp-lzo" compression on their links, I have "comp-lzo" in the server's configuration file so it's turned on by default. I now need to add a new type of client, a MikroTik router, whose OpenVPN client doesn't support "comp-lzo". I have tried adding [code]comp-lzo no[/code] to the client's ccd file, however I'm still seeing "Bad LZO decompression header byte: xx" messages in the VPN server's syslog when this client connects, and the client and server are unable to ping each other through the link. Am I missing something? Shouldn't this directive prevent LZO from being used for this client? Or am I going to have to remove "comp-lzo" from the server config, and add it to every [i]other[/i] client's ccd file?

Disable comp-lzo for just one client

jms1

I have an OpenVPN server with about 300 existing clients, running a mixture of Linux, Mac OS X, iOS, Android, and Windows. Because all of these clients are using "comp-lzo" compression on their links, I have "comp-lzo" in the server's configuration file so it's turned on by default.

I now need to add a new type of client, a MikroTik router, whose OpenVPN client doesn't support "comp-lzo".

I have tried adding

comp-lzo no

to the client's ccd file, however I'm still seeing "Bad LZO decompression header byte: xx" messages in the VPN server's syslog when this client connects, and the client and server are unable to ping each other through the link.

Am I missing something? Shouldn't this directive prevent LZO from being used for this client? Or am I going to have to remove "comp-lzo" from the server config, and add it to every other client's ccd file?

maikcat

AFAIK not every directive can be placed and used inside ccd files,

f.e you cant have AES cipher for one session and BF for another...

Michael.

jms1

True, but in "man openvpn", the description of the "--comp-lzo" option contains...

--comp-lzo [mode]
      Use  fast LZO compression -- may add up to 1 byte per packet for
      incompressible data.  mode may be  "yes",  "no",  or  "adaptive"
      (default).

      In  a server mode setup, it is possible to selectively turn com-
      pression on or off for individual clients.

      First, make sure the client-side config file  enables  selective
      compression by having at least one --comp-lzo directive, such as
      --comp-lzo no.  This will turn off compression by  default,  but
      allow  a  future  directive  push from the server to dynamically
      change the on/off/adaptive setting.

      Next in a --client-config-dir file, specify the compression set-
      ting for the client, for example:

          comp-lzo yes
          push "comp-lzo yes"

      The  first line sets the comp-lzo setting for the server side of
      the link, the second sets the client side.

... which leads me to believe that the "comp-lzo" option can be used in a ccd file.

It also suggests that using "comp-lzo no" globally, and then "comp-lzo yes" in each of the LZO-capable client files, is one way to accomplish what I need to do. I was trying to avoid having to stop and restart the entire VPN, but if it's my only choice, I have to do it...

jms1

Other than the "client config", this is exactly what I'm currently doing on my server - the server's config has 'comp-lzo' (with no argument) in it, and the client's ccd file contains both 'comp-lzo no' and 'push "comp-lzo no"'.

The client here is a MikroTik router. The MikroTik docs say that it doesn't support LZO at all, so I suspect it doesn't support dynamically negotiating LZO either.

If the server config contains 'comp-lzo no' and the ccd file contains no mention of 'comp-lzo' at all, would this cause the server to not even try to negotiate LZO? And in this case, can I still add 'comp-lzo yes' and 'push "comp-lzo yes"' to the individual ccd files, so these clients may continue to use LZO?

jms1

I am seeing the "OPTIONS IMPORT: LZO parms modified" message, however ... with or without the 'push "comp-lzo no"' in there, I still get the "Bad LZO decompression header" messages, and I still get a non-working link (as in, the client router cannot ping the server's IP within the tunnel, and the server doesn't consider the client to even be connected in the first place.)

I have declared a maintenance window later this evening, and I will try putting "comp-lzo no" into the server's config at that time.

jms1

Maintenance window. The server's config now contains "comp-lzo no", and the ccd files don't contain any mention of LZO at all.

The existing clients were able to immediately dial back in when the service restarted, with no ccd changes needed.

The behaviour of the MikroTik router is unchanged, and I'm still seeing the "Bad LZO decompression header" messages in the log. I would have expected these to go away, with the server's configuration having "comp-lzo no" in it...

The server is running "openvpn-2.3.2-2.el6.x86_64.rpm" from the EPEL repo, on CentOS 6.

The client is a MikroTik RB2011iL router, using RouterOS 6.18 (their latest version.) I have no idea what version of OpenVPN their firmware is based on, but from what I've been reading, it sounds like MikroTik has pretty much stopped all development on OpenVPN.

I know there is at least one bug in the MikroTik OpenVPN client code (when the server sends an IP and mask, the router assigns the IP with a /32 mask, and uses the subnet mask value from the server as the "network" value) but I've been trying to work around it, if possible.

http://forum.mikrotik.com/viewtopic.php?f=2&t=87802

It looks like I have no choice but to set up an IPSEC point-to-point link between this router and another MikroTik router here in the office.

Thank you to everybody who tried to help with this.