Struggling with new iOS client 3.4+
Posted: Sat Dec 02, 2023 11:54 pm
We have what has been a stable VPN setup. Main use case is gaining access to the home network from outside, less often for protection on public wifi.
I found the other day that OpenVPN Connect on my iPhone and iPad had gotten updated to 3.4.1 since the last time I'd used the VPN. And that it no longer worked. Launching the app would briefly give a splash screen, then just go black. Same on both device types. No getting past it.
Deleted and resinstalled the apps, loaded config files with two changes: commented out "comp-lzo" and replaced "tls-client" with client. We have two distinct OpenVPN servers with outward facing ports. Tried the first, didn't work, commented out "comp-lzo" on that server, restarted it, all good.
Did the same changes to the second. Connection happens, but the log is full of "Bad LZO decompression header byte: 69", which means the server is still expecting compressed data and the client isn't sending such. The server that is behaving is running 2.4.6, the one that isn't is running 2.4.4.
Was there a bug fixed between 2.4.4 and 2.4.6 that might explain this discrepancy?
And a different question: it seems "comp-lzo" got deprecated with predujice in the iOS apps at 3.4. I understand crypto applied to compressed data can weaken security. But what have others done? Is there some better compression option we should be using on both ends of this equation?
Thanks in advance for any insight or direction.
--Richard
I found the other day that OpenVPN Connect on my iPhone and iPad had gotten updated to 3.4.1 since the last time I'd used the VPN. And that it no longer worked. Launching the app would briefly give a splash screen, then just go black. Same on both device types. No getting past it.
Deleted and resinstalled the apps, loaded config files with two changes: commented out "comp-lzo" and replaced "tls-client" with client. We have two distinct OpenVPN servers with outward facing ports. Tried the first, didn't work, commented out "comp-lzo" on that server, restarted it, all good.
Did the same changes to the second. Connection happens, but the log is full of "Bad LZO decompression header byte: 69", which means the server is still expecting compressed data and the client isn't sending such. The server that is behaving is running 2.4.6, the one that isn't is running 2.4.4.
Was there a bug fixed between 2.4.4 and 2.4.6 that might explain this discrepancy?
And a different question: it seems "comp-lzo" got deprecated with predujice in the iOS apps at 3.4. I understand crypto applied to compressed data can weaken security. But what have others done? Is there some better compression option we should be using on both ends of this equation?
Thanks in advance for any insight or direction.
--Richard