Upgrade to OpenVPN 1.2.5 (iOS): issues

[peter_sm]

And ad also support for elliptic curve

[GainfulShrimp]

In case it helps others who were caught out by this...

After renaming my .p12 file to .ovpn12 (then right-click > Get Info, so my Macbook would actually honour the file extension change), and transferring via iTunes File Sharing, the ovpn12 file was not detected properly and I kept seeing the same old "No certificates are present in the keychain".

In the end, I had to email the ovpn12 file to myself and open the attachment on my iPhone using the "copy to OpenVPN" option after tapping the attachment. Unlike the File Sharing method, the email attachment method triggered a prompt in OpenVPN Connect for me to enter my p12 passphrase, and the certificate was then available for choosing for my ovpn profiles.

I'm still struggling to get all of my ovpn profiles working in 1.2.5 though... it seems really flaky. Sometimes a given ovpn will work from the app, sometimes it will instantly change to 'disconnected' - yet the same ovpn will work from Settings > VPN. Other times, the reverse will be true.
With the previous version of OpenVPN Connect, I could use any of my three profiles easily and reliably, from either the app or via Settings > VPN.

[ordex]

I'm still struggling to get all of my ovpn profiles working in 1.2.5 though... it seems really flaky. Sometimes a given ovpn will work from the app, sometimes it will instantly change to 'disconnected' - yet the same ovpn will work from Settings > VPN. Other times, the reverse will be true.
With the previous version of OpenVPN Connect, I could use any of my three profiles easily and reliably, from either the app or via Settings > VPN.

could you please the logs of the non-working attempts to iOS @ openvpn . net please?
They may contain information about the failure.

Thanks

[GainfulShrimp]

I seem to have resolved the problem with my last non-working profile in this recalcitrant new version by:

1. Selecting the non-working profile
2. Tapping Certificate
3. Tapping Reset at the top-right - despite the correct (and only available) cert already being selected
4. Choosing the (exact same) certificate again

When I tried connecting again after the above 'reset' procedure, the profile connected fine, as expected.

I then quit the app and found I could choose/connect any of my three profiles from Settings > VPN.

Now that all three .ovpn profiles are working from Settings > VPN, I'm going to leave the app well alone!

[GainfulShrimp]

could you please the logs of the non-working attempts to iOS @ openvpn . net please?
They may contain information about the failure.

Thanks ordex. With trepidation, I've just retried this and I've realised I'm experiencing the same issue as seanob mentioned earlier:

I did notice when switching between my VPN servers in the app, that I got the “OpenVPN profile is not selected”. I had to go to the iOS VPN settings and choose the server from there, then return back to the OpenVPN app and connect. Never had to do that with previous versions so not sure if that is a bug or by design in the latest version.

I use three ovpn profiles and - now that they're successfully setup in the app - I can only successfully switch between them using Settings > VPN.

For example, if I have ProfileA selected in Settings > VPN, then I can only connect to ProfileA in the app. If I try to select ProfileB in the app, when I try to connect, I immediately get a yellow exclamation symbol and "OpenVPN profile not enabled" message, and ProfileA is auto-selected for me. No new logs are created (logs are present, but only from previous connections).

Similarly, if I go back to Settings > VPN and choose Profile B, then I can't connect to either ProfileA or ProfileC via the app. If I try to select ProfileC from the app and connect, I get the same yellow triangle "profile not enabled" error and ProfileA is auto-selected for me. Again, with no logs.
ProfileA (the first in the list) is always auto-selected at the time the yellow triangle error appears, even if I have ProfileB selected in Settings and ProfileC selected in the app.

Another interesting point: I've just noticed that if I select a profile in the app, then use app switcher to go to Settings, I can see the 'tick' move to my new selection. If I then switch back to the app, the connection succeeds.

In summary:

• Switching profiles always works if done via Settings > VPN
• Switching profiles only works from the app if you go to Settings after selecting the new profile (you can see your new profile getting selected here), then return to the app

In case it helps, I'm using iOS 11.2.2 on an iPhone X.

[Robyn]

The biggest issue for me in this release (compared to 1.1.1) is that the Network State Detection system does not work anymore. Previously, when switching networks or enabling / disabling airplane mode would result in a succesful reconnection attempt (OpenVPN would simply pause the connection during network changes).

Now, when using a UDP connection and the network state changes, this results in a disconnect. When using a TCP connection, the connection does not pause and when iOS reestablishes the network connection, OpenVPN shows that it is connected but internet connectivity is effectively lost (iOS still shows all the indicators and the VPN symbol).

[agelwarg]

I had a working mobileconfig deployed profile with connect on demand. After upgrading to 1.2.5, that stopped working. I followed the instructions to separately add my p12 cert via an .ovpn12 extension, and now I can see the cert in the OpenVPN app. However, it still won't connect and I see no logs (on either side). I'm not sure where / how I am supposed to reference this certificate in the (openvpn connect) config because I had previously bundled the cert along with the config when building the mobileconfig profile through the Apple Configurator AND selected it.

Again, one of the main problems is there are no logs so I can't even see anything helpful about why it's not working...I assume it's cert-related though.

[ahx-fos]

4. After enabling 'save password', the radio button to indicate a connection stays to the left, meaning you have an open connection, but no green radio button.

Just rephrasing with my own words to make sure I understood:
1. you enter a password and save it
2. you click on the connect button
3. the connection starts and the profile gets connected
4. even though the point above is true, the connect button remains grey and on the left

Could you confirm if the above is correct?

Thanks a lot

Confirmed. Correct.

[ahx-fos]

How did this release ever pass QA? It is clearly not fit for purpose!

[ordex]

could you please the logs of the non-working attempts to iOS @ openvpn . net please?
They may contain information about the failure.

Thanks ordex. With trepidation, I've just retried this and I've realised I'm experiencing the same issue as seanob mentioned earlier:

I did notice when switching between my VPN servers in the app, that I got the “OpenVPN profile is not selected”. I had to go to the iOS VPN settings and choose the server from there, then return back to the OpenVPN app and connect. Never had to do that with previous versions so not sure if that is a bug or by design in the latest version.

I use three ovpn profiles and - now that they're successfully setup in the app - I can only successfully switch between them using Settings > VPN.

Are these profile imported via mobileconfig or via .ovpn files? Were they ported from the old version or did you install them after the upgrade?

Please, don't forget about the log too.

Thanks

[kaloprominat]

Hi, everybody! Just want to point app maintainers to that fact, that with this update our corporate mobile ios VPN became broken.

We're using MDM server to push .mobileconfig profiles with certificate and vpn setting for OpenVPN Connect. It's a custom SSL VPN with identifier "net.openvpn.OpenVPN-Connect.vpnplugin". We've got our MDM installation of ~1,5K mobile devices so far, and every device get its own configuration with unique certificate from MDM "over the air". So, after upgrade to version 1.2.5 it doesn't work anymore. And as far as i understand, with all changes in new version, it would not work anymore that way. We're unable to manually import 1,5K unique certificates into all devices. Please, consider our needs. Such huge and backward incompatible changes breaks our mobile VPN.

[ordex]

Hi, everybody! Just want to point app maintainers to that fact, that with this update our corporate mobile ios VPN became broken.

We're using MDM server to push .mobileconfig profiles with certificate and vpn setting for OpenVPN Connect. It's a custom SSL VPN with identifier "net.openvpn.OpenVPN-Connect.vpnplugin". We've got our MDM installation of ~1,5K mobile devices so far, and every device get its own configuration with unique certificate from MDM "over the air". So, after upgrade to version 1.2.5 it doesn't work anymore. And as far as i understand, with all changes in new version, it would not work anymore that way. We're unable to manually import 1,5K unique certificates into all devices. Please, consider our needs. Such huge and backward incompatible changes breaks our mobile VPN.

Hi, we are currently working with Apple to see what are our options in terms of importing certificates via mobileconfig profiles. Unfortunately the new API is much more stringent and doe snot allow direct access to the iOS keychain. As soon as we will get an answer, we will follow up on this too.

[ordex]

I had a working mobileconfig deployed profile with connect on demand. After upgrading to 1.2.5, that stopped working. I followed the instructions to separately add my p12 cert via an .ovpn12 extension, and now I can see the cert in the OpenVPN app. However, it still won't connect and I see no logs (on either side). I'm not sure where / how I am supposed to reference this certificate in the (openvpn connect) config because I had previously bundled the cert along with the config when building the mobileconfig profile through the Apple Configurator AND selected it.

after importing the profile, if it is missing the cert/key entries, the app will show a line called "Certificated" right above the status. If you click that line, it will open the certificate list.

[Robyn]

The biggest issue for me in this release (compared to 1.1.1) is that the Network State Detection system does not work anymore. Previously, when switching networks or enabling / disabling airplane mode would result in a succesful reconnection attempt (OpenVPN would simply pause the connection during network changes).

Now, when using a UDP connection and the network state changes, this results in a disconnect. When using a TCP connection, the connection does not pause and when iOS reestablishes the network connection, OpenVPN shows that it is connected but internet connectivity is effectively lost (iOS still shows all the indicators and the VPN symbol).

This is what happens when going into airplane mode when connected to a server through UDP and disabling airplane mode again.
In other words, disabling airplane mode does not lead to reconnecting. When changing from Wifi to mobile, the error is line-by-line the same.

Code: Select all

2018-01-09 16:00:29 UDP send error: SYSTEM/Can't assign requested address
2018-01-09 16:00:29 Transport Error: EADDRNOTAVAIL: Can't assign requested address
2018-01-09 16:00:29 EVENT: TRANSPORT_ERROR EADDRNOTAVAIL: Can't assign requested address [ERR]
2018-01-09 16:00:29 Client terminated, restarting in 5000 ms...
2018-01-09 16:00:29 Raw stats on disconnect:
  BYTES_IN : 26478
  BYTES_OUT : 13793
  PACKETS_IN : 92
  PACKETS_OUT : 114
  TUN_BYTES_IN : 10231
  TUN_BYTES_OUT : 23391
  TUN_PACKETS_IN : 106
  TUN_PACKETS_OUT : 83
  NETWORK_SEND_ERROR : 1
  TRANSPORT_ERROR : 1

[ordex]

The biggest issue for me in this release (compared to 1.1.1) is that the Network State Detection system does not work anymore. Previously, when switching networks or enabling / disabling airplane mode would result in a succesful reconnection attempt (OpenVPN would simply pause the connection during network changes).

Now, when using a UDP connection and the network state changes, this results in a disconnect. When using a TCP connection, the connection does not pause and when iOS reestablishes the network connection, OpenVPN shows that it is connected but internet connectivity is effectively lost (iOS still shows all the indicators and the VPN symbol).

This is what happens when going into airplane mode when connected to a server through UDP and disabling airplane mode again.
In other words, disabling airplane mode does not lead to reconnecting. When changing from Wifi to mobile, the error is line-by-line the same.

Code: Select all

2018-01-09 16:00:29 UDP send error: SYSTEM/Can't assign requested address
2018-01-09 16:00:29 Transport Error: EADDRNOTAVAIL: Can't assign requested address
2018-01-09 16:00:29 EVENT: TRANSPORT_ERROR EADDRNOTAVAIL: Can't assign requested address [ERR]
2018-01-09 16:00:29 Client terminated, restarting in 5000 ms...
2018-01-09 16:00:29 Raw stats on disconnect:
  BYTES_IN : 26478
  BYTES_OUT : 13793
  PACKETS_IN : 92
  PACKETS_OUT : 114
  TUN_BYTES_IN : 10231
  TUN_BYTES_OUT : 23391
  TUN_PACKETS_IN : 106
  TUN_PACKETS_OUT : 83
  NETWORK_SEND_ERROR : 1
  TRANSPORT_ERROR : 1

Thanks for the log. I am opening an internal ticket with this information.

[mvonk]

Hi, everybody! Just want to point app maintainers to that fact, that with this update our corporate mobile ios VPN became broken.

We're using MDM server to push .mobileconfig profiles with certificate and vpn setting for OpenVPN Connect. It's a custom SSL VPN with identifier "net.openvpn.OpenVPN-Connect.vpnplugin". We've got our MDM installation of ~1,5K mobile devices so far, and every device get its own configuration with unique certificate from MDM "over the air". So, after upgrade to version 1.2.5 it doesn't work anymore. And as far as i understand, with all changes in new version, it would not work anymore that way. We're unable to manually import 1,5K unique certificates into all devices. Please, consider our needs. Such huge and backward incompatible changes breaks our mobile VPN.

Hi, we are currently working with Apple to see what are our options in terms of importing certificates via mobileconfig profiles. Unfortunately the new API is much more stringent and doe snot allow direct access to the iOS keychain. As soon as we will get an answer, we will follow up on this too.

Can't you just revert to using the old API, which worked? Because the API itself has not changed, only the OpenVPN client. So, somewhere down the line of several updates, you changed something. And this made the app unable to get the cert from the keychain. So, if you would just revert back to the old model of retrieving the cert from the keychain, it should work again.

Also, why was this issue not found during Q/A? It seems to affect a lot of customers and users, so I assume this particular use-case would need to be part of the Q/A testing.

[ahx-fos]

Can't you just revert to using the old API, which worked? Because the API itself has not changed, only the OpenVPN client

I suspect the API is being deprecated hence the change to the new public one being required. I'll check my Apple Developer notes later today and see what I can find out, but I strongly suspect that's the reason.

Regardless though, this was communicated terribly! This critical change isn't even in the damn initial release notes within the AppStore! (which I note this morning have now been fully updated - too late now unfortunately.)

Also, why was this issue not found during Q/A?

It clearly wasn't QA'ed. If it was, the QA Director needs to be made redundant after this shambles. This is possibly one of the worst App upgrades I have witnessed in 10 years of iOS development.

[ahx-fos]

With the latest 1.2.5 version, we can also confirm that custom DNS settings are not propagating to our users. How can we help to get this resolved as fast as possible?

*sigh*

Was _anything_ tested in this junk before it was released?

[Zephyer]

Hi there,

Can you give me an insight on why;

- you keep pointing at Apple while openVPN 1.1.1 was able to work with iOS 11.x (+ beta’s),
- you won’t release 1.2.6 with the code from 1.1.1 and go back to the drawing board? With this you would be helling out your users with a working version instead of holding back on info and asking for logs... release a beta (1.2.7) that people can test and with that upload logs?

[anatoli]

Version 1.2.6 with the code from 1.1.1 seems like THE solution for all the problem at this time. Trying to fix all the problems now would take a lot of time and the fixes made in a hurry could introduce new problems themselves. The situation is rather critical.