I’m not sure which version it came in on but somewhat recently, I was able to duplicate the problem when I installed version 1.2.3236.80 and it persists to the current 1.3 release.
For openVPN connections on MacOS (I have been unable to verify if our Windows users have this problem) connections are making use of lzo compression regardless of
compression being disallowed on the server
compression options in the client (absent, comp-lzo no, compress stub-v2)
This result in a connecting but no communication passing between client and server, culminating in an inactivity timeout. The server log is flooded with
IP packet with unknown IP version=15 seen
from the offending client(s).
The only way I’ve found to deal with this is to explicitly push ‘compress stub-v2’ to all clients from the server.
This happens to clients connecting to openvpn 2.5.x versions on both pfSense and OPNSense systems. Can’t seem to find anyone else anywhere who’s noticed this. Perhaps most client users are connecting to PriTunl servers?
OK, that pointed me in a direction and I think I now see how things work and what’s going on here (and how my topic could perhaps use a title modification…)
To answer the specific question: ‘comp-lzo no’
I think I see the issue and it may have started here: bebcfad
It’s probably done for a reason (I’m guessing to handle the current mess with changing compression options between OpenVPN versions) but it looks like
comp-lzo y/n is always included
additionally, compress options in the original .ovpn are filtered and converted to comp-lzo no
‘comp-lzo no’ still enables compression framing, which is a connection breaker with any server where you set ‘allow-compression no’
This did help me find another server-side fix that I prefer slightly better… ‘allow-compression asym’, which is actually the current default in the openVPN man page. That lets me push an empty compress option (actually it’s done for me in pfsense) and the client/server work just fine in that case.
Still don’t like pushing a compress option to all clients (users of OpenVPN connect, our 2nd-place approved client, are just fine with no compression options) but it’s an improvement from where I started.
OpenVPN configuration files have several ways of causing code execution. Although it will only happen if the user imports a malicious OpenVPN configuration file it will allow privilege escalation because the internal service runs the configuration files as root. This has caused several local privilege escalation issues with the client. To stop this the internal service will now only permit the specific configuration options used by Pritunl servers. This is done in service/parser/ovpn.go
I’ve updated the parser to not default to comp-lzo no but any non-Pritunl configuration file will still need to conform to the limited options available in the parser.
Makes sense, seeing as how you’re rolling a complete suite.
After getting a better understanding of what was going on I figured we’d have to live with it if we wanted to keep this client (until these options go away anyway). We do… so much appreciated.