Setting up OpenVPN failing at TLS_ERROR

[dobler]

I can not successfully get OpenVPN to work. I have followed every video tutorial I can find and have looked up this error message on Google, yet still I can not get OpenVPN working on PFSense 2.0.1. I have exported the openvpn configuration through the installable package in pfSense. The outputted file looks like this:

dev tun
persist-tun
persist-key
proto udp
cipher AES-128-CBC
tls-client
client
resolv-retry infinite
remote 198.71.250.201 1194
tls-remote "VPN Server Cert"
auth-user-pass
pkcs12 pfSense-udp-1194.p12
tls-auth pfSense-udp-1194-tls.key 1
comp-lzo

This is the message I am receiving when trying to connect from a windows client:
TLS_ERROR: BIO reads tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGTERM[soft,tls-error] received, process exiting.

• I have checked the system clock. It is correct.
• I have followed these tutorials exactly http://www.youtube.com/watch?v=odjviG-KDq8 and http://www.youtube.com/watch?v=VdAHVSTl1ys
• I checked the TLS key, it matches.

still, it refuses to work. Any troubleshooting ideas? From the tutorial, it looks like this should be easy to do.

UPDATE:
I have tried multiple clients now. still no go. Next I am going to try reinstalling a fresh pfSense. Certainly it should work then right?j

UPDATE 2:
So now I have tried this same procedure on a fresh install of pfSense (my current installation i have been using for more than a year.) and I still am receiving this log from OpenVPN:

Checking reachability status of connection…
Connection is reachable. Starting connection attempt.
Sep 07 20:13:32: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Sep 07 20:13:32: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Sep 07 20:13:32: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sep 07 20:13:32: Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Sep 07 20:13:32: LZO compression initialized
Sep 07 20:13:32: UDPv4 link local (bound): [undef]:1194
Sep 07 20:13:32: UDPv4 link remote: 198.71.250.201:1194
Sep 07 20:13:32: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
Sep 07 20:13:32: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sep 07 20:13:32: TLS Error: TLS object -> incoming plaintext read error
Sep 07 20:13:32: TLS Error: TLS handshake failed
Sep 07 20:13:32: SIGUSR1[soft,tls-error] received, process restarting

Clients:
Viscosity (mac os 10.8)
OpenVPN client (Windows 7) which can not successfully connect to a pfSense 2.0.1 virtual box

Server:
pfSense 2.0.1 (tried a fresh installation) running within Virtualbox on a Solaris system. pfSense install working great as a router and used for some time now.

UPDATE 3:
I have checked my rules and outbound mapping and also tried changing my port used by OpenVPN as suggested in this post:
http://forum.pfsense.org/index.php?topic=18623.0

So I am really out of ideas at this point. :( I could really  use some help.


[Nachtfalke]

When you created the certificates on pfsense manager - did you create one "SERVER" certificate for OpenVPN server and then user certificates for your clients ?

[dajones13]

I am getting the exact same error on a pfSense installation I have.  I had the OpenVPN working and it stopped working. I've removed the configuration and all the certificates several times and always get the same error trying to connect.  I have several other pfSense 2.01 firewalls that OpenVPN road warrior setups work fine on.  The client I'm testing with will connect to other pfSense 2.01 without any issues.  I haven't re-installed from scratch since this is the primary firewall at a customer site.  This firewall is the only one I have that has a multi-wan setup, but I tore all that out and I still get the same error.  In the pfSense logs on the firewall I get the following…

Sep 17 10:00:13 openvpn[49289]: x.x.x.x:2962 TLS Error: TLS handshake failed
Sep 17 10:00:13 openvpn[49289]: x.x.x.x:2962 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep 17 09:59:13 openvpn[49289]: x.x.x.x:2962 LZO compression initialized
Sep 17 09:59:13 openvpn[49289]: x.x.x.x:2962 Re-using SSL/TLS context

Same here, I'm out of ideas on how to fix this…  Thanks.

[jimp]

That isn't a problem with rules, it's a problem with the certificates.

Things to check for:

• Make sure the clocks are correct/current on client and server
• Make sure you don't have any spaces in the common name of the server certificate
• Edit the client config and on the tls-remote line try removing the quotes ("") from around the server certificate CN

[dajones13]

ohh,

That fixed it, when I compared the old client config file to the new client config files, the server cert was in (" ") and the config file didn't include CRs and NLs, so when you open it in notepad it looks like a single line.  I added the returns and removed the quotes on the "tls-remote" line and it's working fine now.  Thanks for the help, it looks like there maybe some tweaking is needed on the export openVPN package.  Thanks again!

-Doug

[jimp]

Well certain configs need the ""'s and others don't. I'm not sure why it seems to only affect certain people and not others.

Does your server certificate's common name have any spaces? or just letters?

[dajones13]

It does have spaces, but I've used the same certificate name of about a dozen systems and only the ones with the updated client export utility seem to have issues connecting, the older client worked fine for me.

-Doug

[jimp]

ok, that's the problem then.

IIRC, older OpenVPN clients didn't need the ""'s in some cases but newer ones accept them just fine.

The real fix is to not use spaces in your CN, though making the quoting optional in the export package may be something we need to do.

[jimp]

New version of the OpenVPN client export package coming up now, quoting the server CN is now optional, and off by default.