Nm figured it out. All I had to do was to add the subnets to the local/remote network(s) in the OpenVPN configuration.

I figured it was something like this. I have over 60 sites, but have narrowed it down to geographical areas. I plan on implementing this in three sites first and then breaking the rest up. Most data will still be going to our data canter, so removing the remote LAN is not an option at the data center. I think I can just setup routes or administrative distances. Thanks for your reply, Dilster

You seem to have forgotten what type of vpn you are using…

You need rule/s on Firewall->Rules, OpenVPN tab, to allow traffic from source OpenVPN tunnel 192.168.30.0/24 to destination LANnet 192.168.20.0/24 - or for a start put a pass all rule (protocol all source any destination any).

Did you figure this out or find a solution?  I think am trying to figure out the same exact thing but having a hard time figuring it out at this time.

Assuming there is a straight forward setup at each end, you either have a routing, firewall, NAT, DNS or application (phone system) issue.  You've stated that both sides can access each other's resources, so the networking should be in place, but I hate to assume, so we need more details: Post a network map, so we have a better idea of how things are connected. Post the server1.conf from server and the client1.conf from the client. Post a screen shot of the firewall rules from the LAN tab and OpenVPN tab on each end What kind of phone system is being used and what is it running on? Are there any blocks in the logs at either end?

@Derelict: Those look like changes so the VPN clients can get out to the internet (not sure about the WAN_DHCP on the OpenVPN tab). You asked about being able to get to hosts on LAN, not the internet. Initially I couldn't ping the LAN or the internet. Somewhere along the way the LAN started working, but the internet held out for a while. While I was able to figure out how I enabled the internet (per the above), I have no idea what I did that got the LAN working. It could have been as simple as rebooting the box (instead of just the OpenVPN service). Thanks for your help.

In Windows, you should have an "Add a new TAP virtual ethernet adapter" shortcut among your programs list (mine points to "C:\Program Files\TAP-Windows\bin\addtap.bat"). Adding an extra adapter could perhaps be a workaround for you, as the OpenVPN connection only uses one of them, the other one will stay disconnected always, maybe fooling your stupid wireless driver about connection state. It's just a try.

How about pushing a default gateway to the clients so that all the traffic would go through your interface?

Yep I had a similar issue here. My WAN IP changed (due to a modem reboot), and then I lost control of openvpn via the web interface… restarting produced the following errors : Mar 16 16:01:00 openvpn[1656]: OpenVPN 2.3.6 amd64-portbld-freebsd10.1 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Dec 1 2014 Mar 16 16:01:00 openvpn[1656]: library versions: OpenSSL 1.0.1k-freebsd 8 Jan 2015, LZO 2.08 Mar 16 16:01:00 openvpn[1790]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mar 16 16:01:00 openvpn[1790]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file Mar 16 16:01:00 openvpn[1790]: TUN/TAP device ovpns1 exists previously, keep at program end Mar 16 16:01:00 openvpn[1790]: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16) Mar 16 16:01:00 openvpn[1790]: Exiting due to fatal error A quick ssh login, pkill openvpn, then restart via the web gui and everything is working fine again.

^ that TCP is layer 4, end-to-end between the end-node devices (a client on your LAN and a server out in the big bad internet somewhere). That end-to-end (re)transmission control needs to stay working so it can cope with any packets lost on some other hop from LAN client<->pfSense<->VPN server<->internet-routers…<->final-destination-server - if you somehow stopped passing those real NACKs and/or retransmissions between the end-nodes then they would be in real trouble. And there is no option on OpenVPN to tell it "use TCP for this OpenVPN hop, but actually do not bother about sending ACKs or checking for packet loss or retransmitting lost packets" - that option is called UDP, use it!

Same question asked and answered here. Things change and attack methods and vulnerabilities change, but to my limited knowledge, this pretty much covers your question. http://security.stackexchange.com/questions/73469/tls-authentication-openvpn-mitm-attacks-on-public-wifi

Disregard.. totally miseed the Host Name Resolution section int eh export utility dialog!

if this is an Active Directory just change group policy to the FQDN and problem does not matter 5 min work to you and on there next login they have the new settings

Again, it's post-NAT so you can't match on the source address.  See the other thread which is the same solution