Windows OpenVPN Clients

[Gil]

I'm trying to connect to an OpenVPN Server: Remote Access (SSL/TLS + User Auth).
I have generated several windows OVPN installers via the client export utility.
I installed 2 of these on one windows pc, BUT only 1 of them works.
The 2nd one will not connect unless i disable the CN matching on the Ovpn server. - or I use the user name & password of the other client.
Each user has their individual user cert.

I checked ovpn configs which are:

Working:
dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-256-GCM:AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote xxx.dyndns.org 1194 udp
verify-x509-name "H2L_Server" name
auth-user-pass
ca 200-HQ-UDP4-1194-TO5_Mobile-ca.crt
cryptoapicert "SUBJ:TO5_Mobile"
tls-auth 200-HQ-UDP4-1194-TO5_Mobile-tls.key 1
remote-cert-tls server

Not Working:
dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-ciphers AES-256-GCM:AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote xxx.dyndns.org 1194 udp
verify-x509-name "H2L_Server" name
auth-user-pass
ca 200-HQ-UDP4-1194-TO5-ca.crt
cryptoapicert "SUBJ:TO5"
tls-auth 200-HQ-UDP4-1194-TO5-tls.key 1
remote-cert-tls server

I am also using the microsoft certifcate storage

[Gil]

I should add that I have exported OVPN clients for both of these to Android and they both work on Android.
It appears to be a windows client issue.
I have re-installed OpenVPN for Windows, and also re-installed both client installers. - with the same issue.

It appears to pull the wrong cert (cn) from the Cert Storage (for one of the clients).

[trixbox]

Can you post openvpn log for client that not work and pfsense?

[Gil]

Log from OVPN Server:
Jan 30 13:59:39 openvpn 97365 27.33.246.109:29238 SIGTERM[soft,delayed-exit] received, client-instance exiting
Jan 30 13:59:34 openvpn 97365 27.33.246.109:29238 SENT CONTROL [TO5]: 'AUTH_FAILED' (status=1)
Jan 30 13:59:34 openvpn 97365 27.33.246.109:29238 Delayed exit in 5 seconds
Jan 30 13:59:34 openvpn 97365 27.33.246.109:29238 PUSH: Received control message: 'PUSH_REQUEST'
Jan 30 13:59:33 openvpn Username does not match certificate common name ("TO5" != "TO5_Mobile"), access denied.
Jan 30 13:59:33 openvpn 97365 27.33.246.109:29238 [TO5] Peer Connection Initiated with [AF_INET]27.33.246.109:29238
Jan 30 13:59:33 openvpn 97365 27.33.246.109:29238 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA.

The portion in bold highlights the issue between username and common name.
The User cert is definitely correctly assigned under the user manager, and has the correct CN:

[Derelict]

("TO5" != "TO5_Mobile")

Right. Make the CN in the certificate match the username used or the username used match the CN in the certificate. Or disable that check.

[Gil]

That's my point!
In the Cert manager pfSense (correctly) reports my CN as TO5, and yet the pfSense OpenVPN server tells me it is TO5_Mobile.
I could uncheck the match, but it's not truely fixing the issue is it.
The error is either with pfSense (Client Export) -or the Microsoft Certficate Storage.
I will push both OpenVPN Client installers on another PC & test.

[Derelict]

Feel free to export the certificate (not the private key) and paste it in chat.

It would probably be good to get the one showing from the Cert manager and the one from the export.

For https connections you can get the certificates (at least the server certificates) actually being used out of wireshark in a packet capture. I do not know if the same is true for OpenVPN or client certificates.

[Gil]

Here are a couple of screenshots:

User Certificate - from the Cert Manager:

User assigned with this Certificate - from User Manager:

User selected for the OpenVPN - from the Client Export:

I can make an Installer that works if I don't select the option to use the Microsoft Certificate Store. (for the TO5 user)

The issue only happens when ALL of the following occur:
||-

• -I install both the TO5 and the TO5_Mobile user into "OpenVPN GUI for Windows"; and
  Both of them use the Microsoft Certificate Store-|

I have done this on 2 separate PC's with the same error on the TO5 client vpn.

Clearly, I have a work-around but there is an issue occuring here with the Microsoft Certificate Store.

[Derelict]

Right. I was more hoping to see the actual certificates in play.

[Gil]

Will attempt to do so, when time allows.
Any further tips to expedite the process would be welcome.
How do I pull the certficate from the Export, given it is in the OVPN User Installer .exe?
Also, I've had a look using mmc but can't find where the OpenVPN Certs are stored.

[Derelict]

You could do another export like OpenVPN inline and pull it out of that for starters.

Not sure on Windows. Sorry.

[Gil]

That's the bizzare thing; the inline conf files work - but not the Installer into the Microsoft Certificate Store. My Android will connect on both users - but Windows will only connect on one.
I tried it on a second set of users with the same result.

Can you try the following and let me know what happens please:

• On an OpenVPN Server (Remote Access SSl/TLS + User Auth) with CN + user matching;
• Create 2 user certs on the same CA (as assigned to the RA-OVPN) - Cert1_CN:"Bob"....and...Cert2_CN:"Bob_Mobile"
• Create 2 Users, "Bob" and "Bob_Mobile" and assign the certs (I used the same passwords for each user)
• Use the client export and generate Windows installers with Microsoft Certificate Storage for each.
• Install the "Bob" User
• Test it - It should work. - then Disconnect
• Install the "Bob_Mobile" and test it - it should also work. - then disconnect
• Go back and Re-test the "Bob" user and it fails - (for me)

[Derelict]

@gil said in Windows OpenVPN Clients:

That's the bizzare thing; the inline conf files work - but not the Installer into the Microsoft Certificate Store. My Android will connect on both users - but Windows will only connect on one.

Well. There's your problem I guess. The client is obviously getting the wrong certificate from the certificate store. I am personally ill-equipped to help you further there.

If you edit the imported configurations in the OpenVPN GUI Client on Windows, what do the configurations look like? Are the calls to the certificate store the same? It sounds like whatever being returned by Windows gets screwed up. Not really sure what we can do about that if both work then don't. That will probably have to be taken straight to OpenVPN.

Does stopping and restarting OpenVPN client have any effect? Rebooting?

[Gil]

@derelict said in Windows OpenVPN Clients:

If you edit the imported configurations in the OpenVPN GUI Client on Windows, what do the configurations look like?

The configs are correct, in that the call their respective certs:

• ca 100-UDP4-40094-Gil-ca.crt
  cryptoapicert "SUBJ:Gil"
  tls-auth 100-UDP4-40094-Gil-tls.key 1
  and;
• ca 100-UDP4-40094-Gil_Mobile-ca.crt
  cryptoapicert "SUBJ:Gil_Mobile"
  tls-auth 100-UDP4-40094-Gil_Mobile-tls.key 1

I agree with your statement:

@derelict said in Windows OpenVPN Clients:

The client is obviously getting the wrong certificate from the certificate store

I have done the usual resets, as well as installing it on another PC, and also on testing the whole scenario on another pfsense server.
I will flag it on the OpenVPN Community, just thought I'd flag it and create some awareness here also.

Happy for anyone else to test the senario ....

[Derelict]

One thing I would try - sort of a shot in the dark - would be changing the CN for Gil_Mobile to Mobile_Gil.

Maybe something is matching the Gil strings in both somewhere.

Also there might be some logging that can be turned up on the client that will display what it is doing in that cryptoapicert call.

[Gil]

@derelict said in Windows OpenVPN Clients:

One thing I would try - sort of a shot in the dark - would be changing the CN for Gil_Mobile to Mobile_Gil.

I thought I'd give it a try, but has pobably added to the confusion a bit.

• CN: "Gil" fails always (as per previous)
• CN: "Gil_Mobile" works; but
  it fails on the first attempt if "Mobile_Gil" has just previously connected
• CN: Mobile_Gil works; but
  it fails on the first attempt if "Gil_Mobile" has just previously connected

The error message from the first attempt on the OpenVPN Server:

Feb 5 21:29:23 openvpn 43450
Gil_Mobile/101.191.59.43:31448 SIGTERM[soft,delayed-exit] received, client-instance exiting
Feb 5 21:29:17 openvpn 43450
Gil_Mobile/101.191.59.43:31448 SENT CONTROL [Mobile_Gil]: 'AUTH_FAILED' (status=1)
Feb 5 21:29:17 openvpn 43450
Gil_Mobile/101.191.59.43:31448 Delayed exit in 5 seconds
Feb 5 21:29:17 openvpn 43450
Gil_Mobile/101.191.59.43:31448 PUSH: Received control message: 'PUSH_REQUEST'
Feb 5 21:29:16 openvpn user 'Mobile_Gil' authenticated
Feb 5 21:29:16 openvpn 43450
Gil_Mobile/101.191.59.43:31448 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Feb 5 21:29:16 openvpn 43450
Gil_Mobile/101.191.59.43:31448 TLS: tls_multi_process: untrusted session promoted to semi-trusted
Feb 5 21:29:16 openvpn 43450
Gil_Mobile/101.191.59.43:31448 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Feb 5 21:29:16 openvpn 43450
Gil_Mobile/101.191.59.43:31448 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
Feb 5 21:29:16 openvpn 43450
Gil_Mobile/101.191.59.43:31448 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1569'
Feb 5 21:29:16 openvpn 43450
Gil_Mobile/101.191.59.43:31448 TLS Auth Error: Auth Username/Password verification failed for peer
Feb 5 21:29:16 openvpn 43450
Gil_Mobile/101.191.59.43:31448 TLS Auth Error: username attempted to change from 'Gil_Mobile' to 'Mobile_Gil' -- tunnel disabled

I think I'm chasing my tail without some better tools and more understanding of the Microsoft Certificate Storage.

I am using the openVPN GUI v11.10.0.0 from OpenVPN Technologies Inc. Not sure if there is an alternate app to test with.

@derelict said in Windows OpenVPN Clients:

Also there might be some logging that can be turned up on the client that will display what it is doing in that cryptoapicert cal

I don't see any additional logging options available.