[Solved] Connection Issues on iOS 12.1 (16B92) using OpenVPN Connect 3.0.2 (894)

an0nymous

EDIT: Wrong assumptions below, take away message: Let OpenVPN in support decide which cipher to take for TLS encryption.

Hello there,

one of our iPhones stopped connecting to our OpenVPN server after updating the client, though all other devices still work and I tested the config/credentials on my own Phone and on another Android device without issues. We even did a full reset of the misbehaving iPhone and installed everything from scratch.

The server logs complain about "no shared cipher" on TLS handshake, whereas the client log reports a timeout. This is only affecting ONE out of a dozen iPhones until now. This is why i believe something might be wrong with OpenVPN Connect on iOS or some ciphers from OpenSSL might be missing in the latest iOS. The current TLS cipher to use is "DHE-RSA-AES256-SHA", which we want to replace with "DHE-RSA-AES256-SHA256", to walk away from SHA, as soon as all devices have proper connectivity again.

I'd file a bug report including client/server logs to https://community.openvpn.net/openvpn/report if there were a Trac button to do so as when I am logged in.

Friends, is there any way to downgrade to an older version of OpenVPN Connect on iOS? Unfortunately, I don't see the older app version in the corresponding iTunes folder.

Best regards
an0nymous

TinCanTech

an0nymous wrote I'd file a bug report including client/server logs to https://community.openvpn.net/openvpn/report if there were a Trac button to do so as when I am logged in.

Being logged into the Forum does not log you into trac.

an0nymous wrote The current TLS cipher to use is "DHE-RSA-AES256-SHA", which we want to replace with "DHE-RSA-AES256-SHA256"

Could it be that you are specifying your TLS cipher incorrectly .. neither of those names is valid for TLS (openvpn) -- You could post your broken client config ..

an0nymous

The TLS Cipher is specified as "TLS-DHE-RSA-WITH-AES-256-CBC-SHA" in the client config. This should adhere to IANA terminology. Though, I noticed that this goes to the UNUSED OPTIONS due to the client's logfile on both the working and the striking device.

an0nymous

Being logged into the Forum does not log you into trac.

I am "logged in as an0nymous" to Trac, but I didn't see a button to file a report. Looks like missing privileges. Anyway, I will only try to file a bug report if it turns out to be a bug in OpenVPN Connect.

TinCanTech

an0nymous wrote The TLS Cipher is specified as "TLS-DHE-RSA-WITH-AES-256-CBC-SHA" in the client config

Which is almost always the problem ..

OpenVPN relies on the SSL library for cryptography so the underlying SSL lib does not agree with your specification, try without specifying it in the client and see what you get.

an0nymous wrote I am "logged in as an0nymous" to Trac, but I didn't see a button to file a report. Looks like missing privileges

It works for me and I've asked the admin if there are any known problems .. but they say it's all working normally.

an0nymous

Thanks, I tried without specifying the TLS Cipher on the client side. Glad to see it does not appear in "UNUSED OPTIONS" in the client's log anymore. Though, the server still complains on connection attempt:

TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

an0nymous

On the since ever working device, without specifying any TLS cipher on the client side, the connection works fine. So I learned that indicating a TLS cipher on the client side, in contrast to some tutorials out there, is not necessary. And may even be a culprit.

TinCanTech

an0nymous wrote I learned that indicating a TLS cipher on the client side, in contrast to some tutorials out there, is not necessary. And may even be a culprit.

Unless you are really familiar with the SSL library(s) in use, OpenVPN always recommend you leave this out of both your server and client config. OpenVPN will do it's best to select the best cipher suites available. If you are only running supported versions of OpenVPN then this is sufficient for most users.

Of course, there are circumstances where this is not the case but they are almost always due to unsupported OpenVPN version.

As your problem with the one client appears to be unresolved I suggest you read this .. We require to see both configs and logs

an0nymous

Awesome advice. 🙂
Since OpenVPN from now on decides on its own which cipher to take, the connection came back to life on the offending device.
But I am :? with the result of the TLS negotiation, so I'd schedule an update to a more recent OpenVPN version and even recommend a Linux upgrade on the server side. Yes, we're on Debian. :-/
Many thanks again.

an0nymous

As your problem with the one client appears to be unresolved I suggest you read this .. We require to see both configs and logs

Thanks, the connectivity issue is resolved.

rtp130

TinCanTech wrote
an0nymous wrote I learned that indicating a TLS cipher on the client side, in contrast to some tutorials out there, is not necessary. And may even be a culprit.
Unless you are really familiar with the SSL library(s) in use, OpenVPN always recommend you leave this out of both your server and client config. OpenVPN will do it's best to select the best cipher suites available. If you are only running supported versions of OpenVPN then this is sufficient for most users.

Of course, there are circumstances where this is not the case but they are almost always due to unsupported OpenVPN version.

As your problem with the one client appears to be unresolved I suggest you read this .. We require to see both configs and logs

Thank you for these details on leaving the cipher out of both the server and client. I had been debugging this issue with my iPhone (iOS 12) for a few days now chasing down the "Force AES-CBC cipher suites" solution which did nothing to resolve my issue.

Removing the tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA line from my iPhone config as well as the server config did solve the problem!

Thanks once again!