"SOLVED" because I got the solution up and running under shorewall. Sorry pfSense - it's been nice with you.

You have to assign your CA to your OVPN server and the user have to get a certificate from the same CA.
For this go to System > user manager > server tab and add your LDAP server there. After it is configured correctly you should see the user at users tab, edit the user and add a certificate.

the people using the VPN wouldn't have a clue on how to change the config

In that case it will be OK to use just a single CA. But our Clients are software developers. I do not need to tell more.  ;)

@jimp:

It's actually 1.2.9 now. Any version 1.2.5 or later is fine for this issue.

I've noticed this too :) updated and all is working great
you guys are the best

I had a similar problem, and adding an NAT rule solved it too.

I am still a bit lost how to route all my internet traffic through the openVPN. If anyone knows a way, i would really appreciate it.

Thanks!

Ok, everything seems to be working splendidly now.  Not sure what I did other than disable NAT on my edge router.  It does take a couple minutes for the DNS to propagate out though, as expected.  I'm guessing there is not way to reduce that.  Thanks again for your advice.  :D

Ahhh ok I appreciate it and sorry for posting it originally in the wrong forum.
And its working now using the autoadd rules from the wizard.
I was able to Frankenstein the config and get it to close out tls auth
Now I just need to figure out why my router is not forwarding the ports to it from outside the network
Thanks again

I actually also got the AD for authentication working for our Openvpn implementation, key is using the extended query option to differentiate between OU, apart this there is nothing much to change in your AD structure.

Great tip! Worked like a charm. Thanks a lot.

Look at the logs on pfSense and the second client.
Also add "verb 4" to the configs both on server and client, to have a more detailed log on what's happening.

@ncolunga:

If pfsense 2.1 uses openssl-1.0.0_10 it shouldn't be affected by this bug. Isn't it?

2.1 and 2.1.1 have vulnerable openssl versions.
https://pfsense.org/security/advisories/pfSense-SA-14_04.openssl.asc

Thanks! - Don't know how I missed that.

This can be closed.

My problem was with the TLS-Auth key. I did have the wrong one. Once I edited the key and added the 1 behind it in my conf it resolved the problem.

As for the GUI it too works. I needed to go into the Advanced settings and enable TLS-Auth and choose my key. It now works like a charm..

Thanks for the help Jimp.

Those are both expected behaviors.

#1 - It doesn't matter if pfSense has the user cert in its database. All that matters is that it's a valid certificate made against the right CA. Deleting the certificate does nothing from a security standpoint. At most it would break the export but that doesn't stop the existing client from working.

#2 - Placing a certificate in a CRL does nothing special until that CRL is used by something (e.g. a specific OpenVPN server). You could revoke a cert from one server while letting it work in another one, provided both OpenVPN servers used different CRLs.

Let's assume the SiteA RoadRunner tunnel is 10.42.42.0/24
On SiteB site-to-site Remote Networks put 10.0.0.0/16,10.42.42.0/24
On Site A RoadRunner server Local Network/s put 10.0.0.0/16,192.168.0.0/16
Then routing will work.

Make sure rules on OpenVPN at SiteA and SiteB allow the traffic to/from those subnets.
Then firewalling will allow the traffic.

I connect in like this all the time, to 1 office, and use the whole internal network across lots of offices.

@cmb:

Choose the WAN interface you want it to use in the Interface drop down, and don't specify nobind, that'll give you what you're looking for.

Ok that's what I have already so I will leave it as is. Thanks

I just tried restarting the VPN and it now works but the other issues of links going down and what not are still pending.  I'll have to see how long this stays connected for.