You just need to export the windows CA cert and key and then import that into PFSense. Then set the OpenVPN server to use that CA. You can create a server cert using that CA as well. Then create the client certs with the windows CA tool, and your PF sense OpenVPN will then recognize those certs because it has the same CA cert. Do the same thing with your CRL as you do for the CA. You will need to manually update the CRL on the pfsense box each time a cert is revoked. You wont really be able to use the client export utility, because the client certs wont exist on the pfsense box (just the CA, and server cert). But it is pretty easy to build up a little openvpn package manually. In your domain you can make the msi for openvpn install and then have their logon script copy their config, plus your global tls-auth key to the client. Then you can use windows tools to export their client cert into a crt and key file so openvpn can use it. I am sure there are some command line utilities to do that. If you name their client cert and key files the same for every user then everyone can share the exact same config file, and the only thing that would be different per client machine is their certs. Also, you have some problems in the screenshots. -Your tunnel network is 'inside' your local network subnet. 192.168.17.0/24 is inside 192.168.0.0/16 I generally use 172 addresses for tunnel networks as they are rarely ever used for other things, and it makes them a bit obvious. -Also, you probably want to turn on NetBIOS over TCP/IP, otherwise you will not be able to access windows file shares and printers and such. Set the IP it asks for to one of your AD servers, and start with h-node, but you may want to experiment with the other node settings if h-node does not work well. In an AD environment, it should work pretty good though.

Phil, It turns out i had a weird outbound nat rule that was screwing everything up. removed that and everything is good to go. thanks for the help :O)

Many https sites have trouble with loadbalancing. For security reasons they assume that when a session is suddenly change source ip, it must be "hacked". it is allways a good idea to create a seperate gateway group in failover-mode for all https traffic, this will reduce trouble with financial transactions

The redirect-gateway def1 does not only add the 0.0.0.0/1 it also adds the 128.0.0.0/1 plus the x.x.x.74/32 pointing to your local gateway. The route commands are to be used in a peer-to-peer connection and not in a PKI. From your description i don't really see what your goal is. If it is to simply have multiple VPN tunnels up and use failover pools between them: In such a setup your routing table isn't relevant anyway. You define gateways and traffic is forced to them directly, bypassing the routing table.

FYI- on 2.1 if you assign the openvpn interface and add a pass rule on its tab, that rule will get reply-to added so that the return traffic will flow back the right way without needing the extra NAT to mask the source address.

2.0.2 should be out in the near future (had a few things hold up the release… still trying to get it out) There are test images out there for 2.0.2, linked in a thread on the forum here. 2.1 will be out in the next few months if all goes well, realistically close to the start of the year, maybe later.

@phil.davis: The DMZ OpenVPN Server end will need rules to allow traffic in from 172.242.242.0/24 - if the existing pass rules on OpenVPN are not wide enough already, then add one. In the DMS OpenVPN Server Advanced box, you can just tell it routes, no need to "push" them from the other end. e.g. route 172.242.242.0 255.255.255.0 This tells the server end that the OpenVPN link is the next hop for reaching 172.242.242.0/24 From your description, I think that is all that is needed - allow the packets into the DMZ pfSense from across the OpenVPN, then give the DMZ pfSense knowledge about how to route the responses back. That did the trick! thanks  ;D

@jimp: I try to hand-deliver VPN configurations where possible, or at least put them into a directory that can only be accessed via something more secure (typically an SCP host set for key-only auth, etc). You're right and I eventually came to the same conclusion.  So I'm sending them a 15+ char disposable pass in an encrypted email that's good for a 3 hour download window from a server that publishes to rotating ports. I've also been using pfBlocker to restrict server access to our local ISPs. It's not a key but it's something.

When I stop OpenVPN service this root disappears. I've tried to reboot it. Also I've tried to re-configure clean installation using i386 and amd64 2.0.1 releases. Similar logs received. I suppose that something has been changed on provider's side and I don't know what to change on my side to make it work.  :-\

The other thing to check is that the devices that do not respond (e.g. 192.168.0.115) do have their default gateway set to your pfSense LAN address (192.168.0.2). Devices like WiFi APs etc often get setup with their IP address/netmask on the LAN, but no-one enters a default gateway for them (or their default gateway is set to some old router address from years ago…). So they talk happily on the LAN, but can't get outside.

I didn't look hard at your pfSense version - 1.2.3. I updated one of those a few weeks ago, but I really have no useful memory of what the menus looked like - and certainly not how VPN was done! Someone else who knows the 1.2.3 menus and VPN please feel free to advise.

Thanks! It works

I created the certs but independent from the wizard. Maybe there went something wrong… I will try it the next few days again and notify about the result.

mhab, I think this is a similar issue i am having which I believe is related to this bug: http://redmine.pfsense.org/issues/2582

Post your smb.conf.