Prompted to download the OpenVPN Connect

[Aub_C]

I have the OpenVPN (openvpn-connect-2.1.3.110) client installed on Mac OSX 10.11.6 and keep getting prompted to download the OpenVPN Connect Client. This is affecting multiple users. Any ideas how to resolve this issue?

Please click here to continue to download OpenVPN Connect.

You will be automatically connected after the installation has finished.

Thank you!

[novaflash]

There are many reasons this can happen. One of them is not actually having a valid SSL certificate on your web interface, another is that your local hosts file keeps getting reset by your antivirus, preventing connect client from adding its own rules. Kindly just look up the Connect Client icon in your system tray and select the option to connect there, and you can get the connection working. After initial installation you don't need the web interface anymore.

[Aub_C]

Unfortunately, we use Okta for third party authentication. It only connects using the web interface. This is still an issue for us. We have multiple openvpn servers. This is happening on all of them. We do have a valid SSL certificate. Anti-virus is not an a problem as we are on Mac OS. Openvpn has the host entries in the hosts file.

Is there anything else we can check?

[justinmchase]

I am encountering this same issue. The issue started immediately after an OSX update was applied.

I am able to connect to the VPN still by using the Connect Client icon and selecting Connect there but unfortunately it does not remember my password in the following UI and it disconnects me every time my machine goes to sleep and having re-lookup my password in the password manager and enter it into this modal window is driving me insane. I really want to fix it so I can connect via browser like it used to, this saves me a lot of time and frustration each day.

I have tried rebooting, and also uninstalling / re-installing the OpenVPN client several times. Here is my OS info:
macOS Sierra
Version 10.12.5

And here is the contents of my hosts file (pertaining to open vpn):

Code: Select all

# BEGIN section for OpenVPN Client SSL sites
127.94.0.1	client.openvpn.net
127.94.0.3	openvpn-client.vpn-staging.mycompany.com
127.94.0.2	openvpn-client.vpn.mycompany.com
# END section for OpenVPN Client SSL sites

Relevant ifconfig:

Code: Select all

10:30:49:justin:~$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
	inet 127.0.0.1 netmask 0xff000000
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	inet 127.94.0.3 netmask 0xff000000
	inet 127.94.0.2 netmask 0xff000000
	inet 127.94.0.1 netmask 0xff000000
	nd6 options=201<PERFORMNUD,DAD>

Any help here would be greatly appreciated!

[justinmchase]

When I look in the browser console I see these error messages:

Code: Select all

detect.png Failed to load resource: net::ERR_INSECURE_RESPONSE

[justinmchase]

But when I curl it I don't get any certificate issues:

Code: Select all

curl -v "https://openvpn-client.vpn.mycompany.com:946/detect.png"
*   Trying 127.94.0.2...
* TCP_NODELAY set
* Connected to openvpn-client.vpn.mycompany.com (127.94.0.2) port 946 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: openvpn-client.vpn.mycompany.com
* Server certificate: http://openvpn.net/localca.html #1497458126
> GET /detect.png HTTP/1.1
> Host: openvpn-client.vpn.mycompany.com:946
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 95
< Accept-Ranges: bytes
< Server: TwistedWeb/9.0.0
< Last-Modified: Sun, 04 Oct 2015 22:39:14 GMT
< Date: Wed, 14 Jun 2017 16:38:26 GMT
< Content-Type: image/png
<
�PNG

IHDR%�V�PLTE�z=�tRNS@��f
* Curl_http_done: called premature == 0
* Connection #0 to host openvpn-client.vpn.mycompany.com left intact
IDA�c`�!�3IEND�B`�1

[justinmchase]

Ok I managed to figure it out. If I navigate directly to this page in chrome:
https://openvpn-client.vpn.mycompany.co ... 7458799693

And then when chrome reports that the site is insecure I can then do Advanced -> Proceed anyway then when I try to connect again it works.

So looking at my cert, it isn't expired it appears to be in the cert manager correctly and is fully trusted and when I curl from the command line it reports no errors with the cert... so for some reason Chrome itself appears to be rejecting the cert even though I have no idea why.

I have an acceptable work around but I just wanted to report this here in case anyone else encounters this issue and it could actually be a bug somewhere in Chrome that is hitting this or a very subtle bug in the cert we are using for our openvpn. If anyone has any more details on this I would appreciate it, thanks!

[novaflash]

From information we've been able to gather so far, something has changed in the behavior towards self-signed certificates recently in Chrome, that is causing this problem. There's really no good way around it with the current method of communication that's being used, so a new method of communication will need to be built. This workaround basically tells Chrome that it's okay to communicate with a self-signed cert and so it works again. But yeah, Chrome breaks this communication by default. Not much we can do about it I'm afraid. We'll just have to wait until a new release of Access Server is made that uses another communication method. Unavoidable I'm afraid.

[bthurber]

Here's what I'm seeing for various browsers on Windows 10:

* Chrome - prompted to download the OpenVPN Connect client. Does not automatically connect

* Firefox - prompted to download the OpenVPN Connect client. Does not automatically connect.

* Edge - actually communicates with the client but connection does not occur and both the client and the web page show the error:

Unexpected error: JSONDialog: spawnProcess: (15623, 'CreateProcessAsUser','An error in a system binary was detected. Try refreshing the PC to fix the problem.')

* IE (shudder) - prompted to download the OpenVPN Connect client. Does not automatically connect.

This is with OpenVPN AS 2.1.6 running on the AWS Marketplace AMI 2.1.4 without OS updates. We do have "real" Cert Authority certs. Antivirus is Windows 10 Windows Defender.

[justinmchase]

Are we sure it isn't a bug in Chrome that can just be fixed? Because it really seems like the cert is valid and there isn't a good reason why it is being rejected.

Also I found this:
chrome://flags/#allow-insecure-localhost

[justinmchase]

This appears to be relevant also:

https://stackoverflow.com/a/42917227/12958

[Speedydowt]

So pleased i found this thread, i've been wondering why web authentication doesn't work as shown on the documentation.

Does anyone know of any progress to this one? I still have the same issue when using Chrome and IE.

it seems as outlined above the certificate presented by the openvpn connect client has a CA which chrome deems as having an invalid Common name (assume because its common name is a URL) and the client certificate it presents hasnt got a SAN associated with it.

I've raised a ticket but wondered if anyone else had anymore insight as to a proper fix or the ability to change the certificate presented by the client.

[Speedydowt]

Sure everyone already knows this, but as previous poster found, that URL openvpn-client.company-domain:946/detect.png? is the offending url which resolves to a local address and is the openvpn connect client.

The certificate it presents is untrusted in chrome because of the following:

First issue is SAN as highlighted above, second issue is CN not valid- unsure if this is the CN of the certificate itself or of the CA?

Have got the CA installed in trusted root authorities (think this is done on the install of the openvpn connect client


i appreciate i'm going over old ground and i know people above have said this will need a re work in order to be fixed, but may help others understand why the issue occurs.

cheers
Tom

[novaflash]

That's nice but the only real solution is a new method of communication between client and server. Otherwise if this issue gets fixed, another obstruction will be added in the future and it will stop working again. It'll be a constant fight against browser security. Better solution is another method of communication. And that's being worked on.