need write ADVANCED push "route 192.168.0.0 255.255.0.0";  - where    192.168.0.0 255.255.0.0  you local network…. good luck...

@jimp: Also if you switched between tun and tap and back (as it appears you have) you must reboot in between. The openvpn interfaces in tun mode would not have an 'ether' line and the IP config wouldn't look like that. THANK YOU!! You're absolutely correct. I have switched between tun and tap mode. I was messing about because I initially didn't have the knowledge of which one did what. On the currently deployed Ubuntu Server interfaces config says TAP, but after investigating it's operating in TUN mode. Weird :/ Anyways, a reboot solved the issue. I'm so used to not rebooting that I never even considered it on a freshly installed VM. Thanks again.

Some notes on using that: First, read all of the text descriptions on the new fields that show up when you switch to TAP. The notes are important. Add a new VPN instance, select tap, fill in all your other info as you want, If you want to provide DHCP to clients, check the box to bridge DHCP, select the interface you will be bridging to, and (optionally) fill in the DHCP server pool. If you fill in the DHCP server start/end it should be a range of IPs outside of your existing DHCP pool. If you leave the IPs blank, it will pass DHCP through to your LAN DHCP server. After you save the VPN settings, go to Interfaces > (assign), assign the new VPN interface. Go to Interfaces > OPTx, enable, leave IP type as "none", save. Go to Interfaces > (assign), bridges tab, bridge the VPN interface and your LAN or whatever internal interface(s) you want. Go to Firewall > Rules, on the VPN interface be sure to add rules there that will pass DHCP and whatever other traffic you want (or just pass any/all).

I had the same problem.  With the OpenVPN client, if you're using Windows 7 or Windows Vista, you need to run the client as Administrator – not meaning an account with administrative rights, but either right-click, run as administrator, or edit the properties of the shortcut to run the client as admin.  It needs this to create a route on your Windows PC.  Running as administrator solved the problem for me.

I got it going, much thanks for the advise and best of all the online youtube video that gave step by step instructions on how to use the wizard on pfsense 2.0. Any one need a hand I'll be happy to help.

If you are using OpenVPN and UDP than try this: OpenVPN Server should listen on LAN interface PortForward from WAN1 to LAN for OpenVPN PortForward from WAN2 to LAN for OpenVPN As far as I know there are "LoadBalancing" problems in OpenVPN and UDP with two or more WAN interfaces. Perhaps you found some more information on the forum relating to UDP und Multi-WAN

Nachtfalke, thank you for explaining this!

From those screenshots it doesn't appear that you have any client certificates, which as justsomeguy6575 found would make that list show up empty. Make some client certificates for users from the same CA as the server certificate and they should show up.

After some additional fiddling with outbound NAT it finally seems to work, in combination with the "just use the openvpn tab". Thanks. Had to reboot the machine before the messages went away though.

did you tried reading other topics or forum search? like this one? http://forum.pfsense.org/index.php/topic,7840.0.html

I did some research and it seems that the hotel's ISP (or their ISP's ISP) is Covad and that Covad has been known to block the UDP protocol in some markets. Luckily, OpenVPN is flexible enough that I can configure it to use the TCP protocol instead of UDP. I will configure an alternate server that uses TCP. Unfortunately, our user is leaving the hotel in a few minutes so she won't get a chance to test the new server.

Okay, seems is working a little better now with DNS. Hoping for more improvements soon.

For what it's worth, we figured out a way to do it with the Cisco ASA 5505.  I was able to issue to the VPN users the IP addresses in the same subnet as the 10.4.0.0/20 network.  Then I had to add some very strange looking acl's allowing 10.4.0.0/20 to talk to 10.4.0.0/20.  That seems very strange to me, but it works. I'd still really like to know how to make this work with Pfsense, so if anyone has any ideas, or has questions about my setup please chime in. Thanks.

this is solved - the config I got through the client exporter expected username + password even though I had configured SSL/TLS Remote Access w/o user auth. Works well now!