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.

Hi Yes Ive dont it and i have it to do load balancing just search for my name and HMA and a nice chap suggested how to do it but create 2 clients create 2 interfaces go to routing add your two interfaces and give it a group name set your fail over rule and user the group name as the gateway sorry I cant give you the full detail but Im late and I need a beer . if you need any help just let me know and if I can I will

Thanks for the Help Jimp. Point 1 and 3 Soled. now i am gonna work on no.2 … will revert back once i have it working. regards

Verify you have Inter-client communication checked in the "tunnel settings" section: [image: inter-clientcommunication_zpsfff947b8.jpg] And then the usual… check that windows firewall isn't blocking it.

OK, now I see what you are doing. The floating rule will work because it applies on all interfaces. Now I understand the interfaces you have, I am surprised that what you did at first did not work. Anyway, happy that it is going now.

I'm bumping this topic because I still haven't found a solution. I have done some more troubleshooting and discovered that the problem lies with the home pfsense gateway not forwarding ip traffic from the tunnel (ovpn interface) to the LAN interface. Basically, everything goes just fine for a while, and then suddenly, the pfSense router ceases to forward the traffic to the LAN. This means that the router itself has full access to the work network. It also means that all work network machines have full access to the pfSense home router on the tunnel IP address. But there is zero connectivity between the home LAN and the work LAN. Any ideas?

You have to set your real WAN connection as the default gateway and then use a firewall rule to point all your LAN traffic to the VPN tunnel. In the system DNS settings you need tohave the IP's of opendns (or your ISP) set. This will get the tunnel working reliably. Now go into your DHCP server LAN settings and enter the opendns IP's into the DNS settings. DHCP clients will now use opendns trough the tunnel instead of the DNS forwarder in pfsense. So no more DNS leak. :) The downside is that not using the forwarder might resolve addreses slower and that you will not be able to use local dns names for devices on your lan. If you really need local dns names you could always setup a DNS server and DHCP server on your LAN using another machine. The main point to remember is to not set the VPN as the default gateway for pfsense itself. The pfsense box needs a working internet connection first, THEN you build the vpn tunnel. The reason it works on bootup in your case is because pfsense will skip to the next tier of gateway if the default is down. After openvpn starts running and creates the VPN interface you have the catch-22 problem you describe.

Known issue at the moment, creator working on a fix. https://forum.pfsense.org/index.php?topic=74948.msg409848#msg409848

wunderbar! Yeah, I have a few other rules but they were created from NAT, and DMZ rules were created by me guided by the pfsense community. The only rules in Lan tab is the anti-lockout rule and the default Lan rule. Now all I have to do is update pfsense to 2.1.2 tonight and hopefully no surprises. Thank you so much.