OpenVPN iOS Win10 Issues

[Xentrk]

That link I posted will point you specifically to iOS problems with a working OpenVPN server linked to compression treatment. Which you don't want anyway.

Many thanks @elorimer. Disabling Compression fixed the iOS issue for me. I had lz4-v2 compression configured on the server. After disabling compression, I exported the updated config file and installed on the iPad. I can now access the admin console. Whoot!

UPDATE
Sigh...but now the Android is broken. I can't access the admin console. I'll test with legacy compression next.

 

[Xentrk]

I changed config to the legacy Adaptive LZO Compression. I can now access the admin console on iOS, Android and Win 10.

 

[madition]

I changed config to the legacy Adaptive LZO Compression. I can now access the admin console on iOS, Android and Win 10.

Oh sweet news! Ill try today, posting results soon - do you know how much the speed/bandwidth is affected by compression?

edit: works for both iOS and Win10 now! Thanks

 

[Jack Yaz]

Oh sweet news! Ill try today, posting results soon - do you know how much the speed/bandwidth is affected by compression?

edit: works for both iOS and Win10 now! Thanks

Iirc compression is less and less useful these days

 

[elorimer]

A few things:

@madition, could you change the title of the thread now? This wasn't about amtm in the end.

The problem here is if there is a mismatch in compression settings, openvpn will form a connection successfully, but no traffic will pass. In part this must be because iOS and Android default to different compression settings. I'm puzzled that adaptive compression works cross platform. If I understand it, adaptive compresses things that might benefit from compression, but doesn't on things that won't. As @Jack Yaz says, compression is less useful because much traffic now is already compressed.

But even adaptive compression might be subject to the VORACLE exploit, I suspect. If a bad actor includes a snippet in a file twice, the compressed version will be smaller than the original by a number of bytes, from which it is possible to extract the key. So it might be worthwhile figuring out how compression can be set to none in a manner that works cross platform.

 

[madition]

A few things:

@madition, could you change the title of the thread now? This wasn't about amtm in the end.

The problem here is if there is a mismatch in compression settings, openvpn will form a connection successfully, but no traffic will pass. In part this must be because iOS and Android default to different compression settings. I'm puzzled that adaptive compression works cross platform. If I understand it, adaptive compresses things that might benefit from compression, but doesn't on things that won't. As @Jack Yaz says, compression is less useful because much traffic now is already compressed.

But even adaptive compression might be subject to the VORACLE exploit, I suspect. If a bad actor includes a snippet in a file twice, the compressed version will be smaller than the original by a number of bytes, from which it is possible to extract the key. So it might be worthwhile figuring out how compression can be set to none in a manner that works cross platform.

Changed title. Gonna mess around later and see what none compression can work out for both iOS and Win10

edit: https://i.imgur.com/olgZa9X.png with these settings the routing works to LAN both for Win10 and iOS - dont have an Android device to test with sorry

 

[elorimer]

As you mess around, it would be helpful to also know which client you are using to connect to your OpenVPN instance. Also, I'm assuming you are importing from Merlin the matching client configuration as well. Also, we are not talking about routing, we are talking about traffic passing over the tunnel.

I poked at this question a little bit. There is a big difference between "Disabled" and "None". To save others the exercise, I think the following is the case:

When the OpenVPN server instance is set for "Disabled" as compression, neither the client nor the server configurations at /etc/openvpn/ contain a compression setting. This means the traffic isn't carried in a frame that can be compressed, and the compression module isn't loaded.

When the OpenVPN server instance is set for "None", the client has the deprecated line "comp-lzo no" and the server has the current line "compress". This means that traffic is framed for compression, and the compression module is loaded, but compression isn't used for sending traffic. This seems to be where OpenVPN is heading (except for the deprecated part), since it allows for either the server or the client to accept compressed traffic if it is specified in the frame, but compressed traffic won't be sent. I'm not clear what happens if the server is set to "Disabled" and the client is set for "None", because then there is mismatch not only in compression but also in framing.

Similarly:

Server: LZO
Server config: compress lzo
Client config: comp-lzo yes
Traffic: Both are sending compressed traffic using the older lzo algorithm. Vulnerable, and going away.

Server: LZO Adaptive
Server config: comp-lzo adaptive (using the deprecated version because compress doesn't accept adaptive)
Client config: comp-lzo adaptive
Traffic: Both are sending compressed traffic during intervals when it is thought to be saving bytes. Vulnerable, and going away.

Server: LZ4 (optimized algorithm for OpenVPN but needing clients 2.4+)
Server config: compress lz4
Client config: compress lz4 (using compress because deprecated version doesn't accept this)
Traffic: Both are sending compressed traffic. Vulnerable, and going away.

Server: LZ4-v2 (more optimized algorithm for OpenVPN but needing clients 2.4+)
Server config: compress lz4-v2
Client config: compress lz4 -v2(using compress because deprecated version does accept this)
Traffic: Both are sending compressed traffic. Vulnerable, and going away.


I don't use iOS, but I note that the release notes for the semiofficial (the blinkt.de client) client 3.0.2 says that compression is "disabled by default". I assume that means the default client configuration is silent and therefore doesn't frame traffic to allow for compression, in which event the matching setting has to be "disabled". This does not seem to be where OpenVPN is heading. I'm not sure whether that means one of our imported client configurations can override this behavior or not.

I couldn't tell what the default behavior is for the blinkt.de android client.

 

[madition]

As you mess around, it would be helpful to also know which client you are using to connect to your OpenVPN instance. Also, I'm assuming you are importing from Merlin the matching client configuration as well. Also, we are not talking about routing, we are talking about traffic passing over the tunnel.

I poked at this question a little bit. There is a big difference between "Disabled" and "None". To save others the exercise, I think the following is the case:

When the OpenVPN server instance is set for "Disabled" as compression, neither the client nor the server configurations at /etc/openvpn/ contain a compression setting. This means the traffic isn't carried in a frame that can be compressed, and the compression module isn't loaded.

When the OpenVPN server instance is set for "None", the client has the deprecated line "comp-lzo no" and the server has the current line "compress". This means that traffic is framed for compression, and the compression module is loaded, but compression isn't used for sending traffic. This seems to be where OpenVPN is heading (except for the deprecated part), since it allows for either the server or the client to accept compressed traffic if it is specified in the frame, but compressed traffic won't be sent. I'm not clear what happens if the server is set to "Disabled" and the client is set for "None", because then there is mismatch not only in compression but also in framing.

Similarly:

Server: LZO
Server config: compress lzo
Client config: comp-lzo yes
Traffic: Both are sending compressed traffic using the older lzo algorithm. Vulnerable, and going away.

Server: LZO Adaptive
Server config: comp-lzo adaptive (using the deprecated version because compress doesn't accept adaptive)
Client config: comp-lzo adaptive
Traffic: Both are sending compressed traffic during intervals when it is thought to be saving bytes. Vulnerable, and going away.

Server: LZ4 (optimized algorithm for OpenVPN but needing clients 2.4+)
Server config: compress lz4
Client config: compress lz4 (using compress because deprecated version doesn't accept this)
Traffic: Both are sending compressed traffic. Vulnerable, and going away.

Server: LZ4-v2 (more optimized algorithm for OpenVPN but needing clients 2.4+)
Server config: compress lz4-v2
Client config: compress lz4 -v2(using compress because deprecated version does accept this)
Traffic: Both are sending compressed traffic. Vulnerable, and going away.


I don't use iOS, but I note that the release notes for the semiofficial (the blinkt.de client) client 3.0.2 says that compression is "disabled by default". I assume that means the default client configuration is silent and therefore doesn't frame traffic to allow for compression, in which event the matching setting has to be "disabled". This does not seem to be where OpenVPN is heading. I'm not sure whether that means one of our imported client configurations can override this behavior or not.

I couldn't tell what the default behavior is for the blinkt.de android client.

Thanks for the explanation elorimer! I tried switch to "none" on the compression but then i have no traffic to the lan or web on PC or iOS.

Do we know when OpenVPN 3.0 is out? I think i run with "none" until a better option is avaible that does work for PC and iOS.

edit: i use the official OpenVPN client on Windows and iOS and importing the config from Asus Merlin.

Thanks

 

[RMerlin]

Do we know when OpenVPN 3.0 is out?

OpenVPN 3 is developped in parallel to 2.x because it's a complete redesign from the ground up. I wouldn't expect OpenVPN 3 to catch up with OpenVPN 2.x for many years, as they have to reimplement everything from scratch.

Also, OpenVPN 3 doesn't look good for embedded devices like routers. It has a much larger software footprint than 2.x (at least at this time).