I did try that first and only the openvpn server settings were restored, no certs.

Do your showing a public IP there 197.130.x.x how do you think your going to talk to 10.0.2.15.. How exactly are you talking to 192.168.56.107? Where are you VM interfaces on this PC?  What VM software are you running exactly? What exactly are you trying to accomplish here?  Are you trying to run your PC behind the VM pfsense connected to your internet for a firewall between your PC and the internet?  If so that does not have anything to do with a vpn connection.. It wouldn't be needed from your pc to pfsense.

And I forgot to mention, before testing the client I removed the default gateway addy from the TAP adapter.  Even though Windows moved the connection to Public, I could still access what I needed to on our work network.

Create the VIP as a 'CARP' type, then select the VIP under Interface in the OpenVPN server.

@Hollander: Could I ask: how do you see if there are DNS-leaks? You could create a firewall rule to allow and log any outgoing traffic on port 53 for the WAN. You should see the only name resolutions will be for pfSense stuff and PIA servers. What's nice about the logging is it deconstructs the packet to determine what hostname was requested to be looked up. If you are interested in logging DNS but just in general check out the thread I started here: How can I record and maybe monitor all DNS requests and replies? If you stop DNS outgoing on the WAN there is a "which came first, the chicken or the egg" problem because then how does pfSense lookup the address for the PIA server you're connecting to, or pfSense to check the latest version of FreeBSD? Also keep in mind about the DNS forwarder if you have that enabled you could leak in certain scenarios. For example I have a pfSense box behind a wireless router. So my router has address 192.168.1.1 and when it assigns an IP via DHCP it offers nameserver 192.168.1.1. So the pfSense WAN IP address is something like 192.168.1.2 for example with nameserver 192.168.1.1. Then the pfSense LAN has a DHCP server (192.168.10.1) that assigns an IP 192.168.10.2 and nameserver 192.168.10.1. When client 192.168.10.2 wants to resolve it sends its request to 192.168.10.1 which is the pfSense DNS forwarder. That then sends the request to 192.168.1.1 which is the wireless router DNS forwarder. I believe that would happen even if I was routing my traffic over OpenVPN because 192.168.1.x is a local route. The setup I have right now is I disabled the pfSense LAN DNS forwarder and the pfSense LAN DHCP instead offers google nameservers. The google nameservers are not a local route so they go over VPN. @Hollander: The military man here says that the order of the rules in NAT is important (VPN should be at the top of the list), whereas some comments below it he says this is not necessary if your VPN is the default gateway. However, I have neither: my PIA VPN is not at the top of the rules in NAT, nor is it the default gateway. But I think my PIA VPN is working - looking at the traffic in the GUI, as well as when I look up my own external IP. So apparently what he writes isn't true  ??? That I don't know about, you may have to start a separate thread to ask that question and get someone's attention. In my rules the OpenVPN PIA is first. Also, unrelated, the biggest issue I've had so far with my setup has been OpenVPN continues to work even after it's terminated due to fatal error. So FYI, you may encounter that. It looks to be a bug.

Assign different tunnel networks to each single VPN server and base your rules on these subnets.

"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