When configuring the openvpn client with LZO compression disabled, the dd-wrt GUI writes
Quote:
comp-lzo no
to it's config. This is incorrect and causes problems on servers that have LZO compression disabled. Communication will not be possible, and server logs will contain messages "unknown IP protocol version=15".
Proper procedure for the GUI would be to not include the comp-lzo directive, when compression is disabled.
I believe this behaviour to be a bug. After a failed attempt to hack the part(s) of DDWRT that create /tmp/openvpncl/openvpn.conf, I resorted to a dirty hack using sed and some scripting:
In case somebody (Brainslayer?) fixes this: could the openVPN GUI be updated to include textboxes for up and down config directives? I envision the textboxes to contain the path to the respective script.
In case somebody (Brainslayer?) fixes this: could the openVPN GUI be updated to include textboxes for up and down config directives? I envision the textboxes to contain the path to the respective script.
When configuring the openvpn client with LZO compression disabled, the dd-wrt GUI writes
Quote:
comp-lzo no
to it's config. This is incorrect and causes problems on servers that have LZO compression disabled. Communication will not be possible, and server logs will contain messages "unknown IP protocol version=15".
Proper procedure for the GUI would be to not include the comp-lzo directive, when compression is disabled.
regarding the man ddwrt uses the correct syntax. so not a problem on our side. also i never have seen this behavior. u should upgrade your servers...
--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 compression 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 setting 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.
Thanks Sash, I'm investigating further with the pfSense crew.
From what I understand now, the root cause is that the options mismatch:
- openvpn cfg on dd-wrt always contains comp-lzo
- openvpn cfg on pfSense does not contain comp-lzo when LZO is disabled.
The error message in server logs "IP packet with unknown IP version=15 seen" makes sense when compression is enabled on one end, while not on the other.
if "comp-lzo" is printed to the configuration, extra lzo bit is added (even if 'no' is specified as option), and this will cause errors if making a connection to another openvpn with no "comp-lzo" printed.
i reported this and suggested that dd-wrt have a drop-down with a 'disabled' option to better reflect the real openvpn options (like tomatousb and other firmwares do) but the ticket was ignored and closed.
if "comp-lzo" is printed to the configuration, extra lzo bit is added (even if 'no' is specified as option), and this will cause errors if making a connection to another openvpn with no "comp-lzo" printed.
i reported this and suggested that dd-wrt have a drop-down with a 'disabled' option to better reflect the real openvpn options (like tomatousb and other firmwares do) but the ticket was ignored and closed.
Ah, right there! Thanks DaveM for the insight. I second your opinion on the "disabled" option as I'm not a fan of quick'n'dirty sed hacks myself
But alas, the trick with disabling compression through a ccd option didn't work out so I'm stuck with that for now. Maybe a mistake on my end, I'll check back when I have more time.
In fact, it's all no problem if you're going to set up a new server; you'll just include "comp-lzo no" in the server config. But stuff gets complicated when you have an existing server (of which you possibly have no control) and are trying to hookup a DD-WRT to it, like I did.
Someone not familiar with the command line will have a very frustrating experience, to say the least. Mine surely was, and it would have been a catastrophic failure if it weren't for my humble *nix skillz... Hence why I posted about the topic after all, so others running into the same situation will have a lead, hopefully saving them a night's worth of work. And hence also why I'd suggest to the dd-wrt devs to consider adding the requested feature none the less.
hmm... first they added support for null cipher/auth, now they added proper comp-lzo support, i hope auth-user-pass is next since sash seems to be in the mood