Heads up, I found on my OpenWrt router (Netgear R7800), running openvpn servers for my mobile devices to connect back home while out and about, the previous compression setting in /etc/config/openvpn did not work and caused a service startup loop.
This works in 19.07, but not in 21.02.0-rc3:
option compress 'lzo'
I had to change it to this:
option comp_lzo 1
after which everything was happy again.
The compression no-no is also mentioned in the OpenVPN manual for 2.5. And the function will be removed in 2.6.
19.07 have OpenVPN 2.4 and 21.02 have OpenVPN 2.5.
But 21.02 was released very late so we didn’t get 2.5 when it got out.
OK thanks for the updates.
Generally speaking, is there a place that an OpenWrt end-user can monitor for incompatible package changes like this? A blog or announcement list?
And then what exactly is option comp_lzo 1 doing for me now? Is it ignored, or is somehow the package I got installed for my OpenVPN server on my OpenWrt router actually implementing this option?
(I likely got this package built from source, I was attempting to use the imagebuilder and it had incompatibilities with the packages since 21.02.0-rc3 packages are still a moving target. But I didn't set any specific options, other than CONFIG_PACKAGE_openvpn-openssl=m)
Upstream OpenVPN project. In general OpenWrt is just following what upstream does, they try to keep custom modifications (especially to large packages like VPNs) at a minimum.
Usually these changes are written in changelogs for new versions.
OpenVPN has a mailing list called openvpn-announce where they post the changelogs https://sourceforge.net/p/openvpn/mailman/openvpn-announce/?viewmonth=202010
And this is an example message, where you see under "important notices" they talk about various breaking changes they did to some other feature https://sourceforge.net/p/openvpn/mailman/message/37304996/
This is what you should do for most other opensource software used in OpenWrt, since in most cases OpenWrt is just repackaging their stuff with little changes, and does not have enough manpower to set up a full system to send you updates on all things that changed or didn't change.
that is not a valid config, where did you read that "comp_lzo 1" does anything? I assume it is ignored by the uci config system and does not generate any change in the actual openwrt config file.
If you actually give it a valid config like option compress 'lzo' OpenVPN tries to do it and then blows up because that function was disabled.
The compression support for LZO has been removed from the binary in 21.02 and master snapshot in the commit linked above. Even if you build from source it is still removed (the build system will compile a new package following the same configuration, where that functionality is removed).
https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
https://community.openvpn.net/openvpn/wiki/WikiStart
Read and you will be enlightened, or fall asleep…
Found it via web search...but now that I think about it, that seems to be an old name for the option before option compress 'lzo'? I took out option comp_lzo 1 and the config fails to work with my iOS devices, blurting this in the openvpn log file:
2021-07-09 20:47:04 JTKphone-openvpn/174.242.75.22:10961 IP packet with unknown IP version=15 seen
So the option seems to be doing something?
If I set it to option comp_lzo '0', the VPN connection also works, so perhaps that is the best solution for now: that seems likely to disable that compression and saves me from having to regenerate the openvpn client's configuration immediately.
Is it possible the openvpn package for OpenWrt retained the server code for LZO compression, and only disabled the client code?
actually, I should set
list push 'comp-lzo no'
option comp_lzo 'no'
to push the no-compression setting to the client during negotiation.
That's redundant since compression is disabled by default.
No the LZO compression is disabled in the server.
It seems that with that option (regardless of 0 or 1 at the end) the server is explicitly telling the client to not use compression (overriding its config?), while without it it just assumes things and the client freaks out when it expects compressed packets and does not get them.
It's hard to tell what is going on without seeing the actual openvpn config file of the server and of the client. That thing is the uci config of OpenWrt but it's used to generate a temporary OpenVPN config file used by the actual service to run.
I don't remember exactly where that is
Even for the client -> server direction? The referenced openvpn man page suggested the push option to the client, from which I infer that the client and server could choose their own options for each direction?
It gets generated as /var/etc/openvpn-<servername>.conf. Notice that comp_lzo gets converted to comp-lzo by something along the way. (If I use option comp-lzo 'no' in /etc/config/openvpn, then the generated config file does not have any comp-lzo or comp_lzo option in it.)
root@LEDE:~# cat /var/etc/openvpn-vpnserver.conf
client-to-client
persist-key
persist-tun
tls-server
ca /etc/openvpn/ca.crt
cert /etc/openvpn/my-server.crt
client-connect /etc/firewall.user
comp-lzo no
dev ovpns0
dev-type tun
dh /etc/openvpn/dh2048.pem
ifconfig-pool-persist /var/run/openvpn.ipp_ucp.txt
keepalive 10 120
key /etc/openvpn/my-server.key
log /tmp/log/openvpn.log
mode server
mute 20
port 1194
proto udp
push "dhcp-option DNS 172.30.11.1"
push "persist-key"
push "persist-tun"
push "redirect-gateway def1"
push "route 172.30.11.0 255.255.255.0"
push "route-gateway dhcp"
push "topology subnet"
push "comp-lzo no"
route-gateway dhcp
server 172.30.11.0 255.255.255.0
tls-auth /etc/openvpn/tls-auth.key 0
topology subnet
verb 3
If you are using the luci-app-openvpn it's in /etc/openvpn
and the client's openvpn config (with certificates elided):
client
dev tun
proto udp
fast-io
remote xxxxxx 1194
remote-cert-tls server
nobind
persist-key
persist-tun
comp-lzo no
verb 3
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<cert>
Certificate:
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
Remove all those options from both server and client.
An as-yet-unanswered question: why does omitting option comp_lzo <anything> from the server's /etc/config/openvpn cause the client (iOS) and server (OpenWrt) fail to communicate, with the server blurting complaints about IP packet with unknown IP version=15 seen, if there is no LZO support in the OpenWrt openvpn server package?
Hm. So in the uci config the option names for openvpn replace "-" with a "_", as seen in this list of defined options https://github.com/openwrt/packages/blob/master/net/openvpn/files/openvpn.options
Anyway, IP packet with unknown IP version=15 seen happens when you have different compression settings in server and client, regardless of LZO being available or not, or you enabling it or disabling it.
Or if you have Ata-over-Ethernet kernel modules enabled (not your case since it's not installed by default in OpenWrt and it's quite frankly a VERY niche thing).
So yeah, in your case it's not a LZO thing but a "config files are not the same on client and on server" thing. And everything blew up when "option compress 'lzo'" could not be used anymore so the config file did not contain "comp-lzo something" and therefore was not "similar enough to the client compression settings".
Adding the option comp_lzo anything lets you add custom config options for openvpn and therefore you could add "comp-lzo something" again and the configs were similar enough to not trigger that error.
see for example
https://forums.openvpn.net/viewtopic.php?t=22672
https://forums.gentoo.org/viewtopic-t-1086424-start-0.html
As for the "why it happens", the answer is "because OpenVPN". It's a complex and capricious beast.