Hi all, I successfully employ openVPN to link TL-WR1043ND wireless routers (openVPN Clients) via WLAN to a pfSense 2.0.1 box (openVPN Server). While working on the project, an issue concerning the [b]comp-lzo[/b] directive came up. See the forum posts at [url]http://www.dd-wrt.com/phpBB2/viewtopic.php?t=152214[/url] and [url]http://forum.pfsense.org/index.php/topic,47156.0.html[/url] for detailed information. Long story short: If the openVPN server has no "comp-lzo" directive printed in its config while the openVPN client has a "comp-lzo no" directive, the result will be inconsistent: While the VPN links up and carries traffic, communication will not be possible. The server logs will reveal why (at least with a verb 9): [quote]IP packet with unknown IP version=15 seen[/quote] I suspect this log message to be the result of some mis-alignment, somewhere. My speculation was that compression was enabled on one end, while not on the other. DaveM from the DD-WRT forum offers more insight: [quote]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.[/quote] Apparently, the problem is that DD-WRT includes a "comp-lzo no" and considers this to reflect "compression disabled" - one would intuitively think so. Obviously this is not the case, there appears to be a breaking difference between "comp-lzo no" and no comp-lzo at all. Could someone close to openvpn development shed some light as to why this is and how to proceed? Thanks Chris

Clarification request on comp-lzo

gridrun

Hi all,

I successfully employ openVPN to link TL-WR1043ND wireless routers (openVPN Clients) via WLAN to a pfSense 2.0.1 box (openVPN Server). While working on the project, an issue concerning the comp-lzo directive came up. See the forum posts at http://www.dd-wrt.com/phpBB2/viewtopic.php?t=152214 and http://forum.pfsense.org/index.php/topic,47156.0.html for detailed information.

Long story short:

If the openVPN server has no "comp-lzo" directive printed in its config while the openVPN client has a "comp-lzo no" directive, the result will be inconsistent: While the VPN links up and carries traffic, communication will not be possible. The server logs will reveal why (at least with a verb 9):

IP packet with unknown IP version=15 seen

I suspect this log message to be the result of some mis-alignment, somewhere. My speculation was that compression was enabled on one end, while not on the other. DaveM from the DD-WRT forum offers more insight:

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.

Apparently, the problem is that DD-WRT includes a "comp-lzo no" and considers this to reflect "compression disabled" - one would intuitively think so. Obviously this is not the case, there appears to be a breaking difference between "comp-lzo no" and no comp-lzo at all.

Could someone close to openvpn development shed some light as to why this is and how to proceed?

Thanks
Chris

janjust

the major difference I can think of is that with

comp-lzo no

in the client config file the server can overrule this using

push "comp-lzo yes"

without this option in the client config file this is not possible.

There's been discussion on how to deal with these parameters, as it would be make more sense to negotiate them between client and server. It would require a change in the OpenVPN protocol itself, however, so don't expect any significant changes before OpenVPN 3.0

gridrun

Here some status update for informational purposes:

Apparently, the issue was resolved in DD-WRT. A patch has been committed by Sash!
So once Brainslayer rebuilds the WR1043ND image, you'll be able to link its VPN client to pfSense without any sed hacks!

To support the SYS and QSS-for-openVPN led functionality, you'll however still need some script hacking. My request for up/down script fields in the GUI got squashed ...

The corresponding thread on pfsense.org can be found here: http://forum.pfsense.org/index.php/topic,47156.msg248219.html#msg248219

gridrun

janjust wrotethe major difference I can think of is that with
comp-lzo no
in the client config file the server can overrule this using
push "comp-lzo yes"
without this option in the client config file this is not possible.

I understand the problem to be "the other way around", actually: If the client contains any comp-lzo directive, the server must do so, too. If the server contains no comp-lzo directive, then clients with the directive can't connect due to comp-lzo bit mismatch in the protocol (this perfectly explains the "unknown IP version" error messages logged by the server). Overruling the client side "comp-lzo no" isn't possible as you can't push the absence of a directive. Or is there a way to tell a server to have connecting clients ignore portions of their config?

The behaviour is perfectly understandable and makes sense - except for the comp-lzo no case. It remains unclear to me why "comp-lzo no" should differ from not having any comp-lzo directive in a practical sense?