@kyreservoirdog: jg3, did you ever get this figured out? I did — apologies for not reporting back (bad form!).  I'm glad that you solved it but for the record: I have a 1:1 NAT for an host using an additional public IP (not the IP of the firewall).  There's a corner case or two where VPN'd clients would want to reach the internal host via the public IP.  So I had created another public-private 1:1 NAT rule and applied it to the OpenVPN interface.  This worked to solve the aforementioned problem, but caused the host the NAT applied to not to be able to connect to  VPN clients (other hosts on the internal nework could still connect to VPN clients). So, if you've come here looking for help … about all I can tell you is:  don't do that. --jg3

Found a fix at last, and would like to share it with you. it turns out that the ISP has changed some of their backbone routers. & I ended up doing this. 1. add mtu-test command in the advanced box of the Main OVPN Server. 2. check the logs of ovpn. 3. verify whats the local/remote mtu value 4. add the following to both local & remote (in advanced box) fragment 1400; mssfix;

Has anybody a similar configuration that works?

For anyone looking at this, i found the best guide to use here: http://hardforum.com/showthread.php?t=1663797

Yep that was my issue. Thanks!

Too easy  ;) Tested and fine. Could this be documented in the Wiki?

Op (I, that is) didn't take this OpenVPN FAQ seriously enough: One of the most common problems in setting up OpenVPN is that the two OpenVPN daemons on either side of the connection are unable to establish a TCP or UDP connection with each other. This is almost [always] a result of: … A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194 [here 5000-5007]. Be aware that many OSes will block incoming connections by default, unless configured otherwise. There's no problem with OpenVPN. I just neglected to create a firewall rule for WAN in the pfSense VM that's running the OpenVPN servers, to provide access for the hidden-service proxy in the Tor-gateway pfSense VM. How embarrassing. But this question should remain, I think, in case others make the same dumb mistake that I did.

Yes, in fact it just happened to me again with another VPN profile… Tunnelblick defaults to 2.2, so people that use Tunnelblick by default will have trouble with this until they change the OpenVPN version!  

as far as i know 1.1.4 and 1.1.5 have the verifiy-x509 removed for only the Yealink phones se this thread: http://forum.pfsense.org/index.php/topic,68398.15.html

Thanks for your reply.  I decided to abandon this configuration and instead not user OPTx interfaces for the OpenVPN tunnel interfaces.  Also I realized I don't need NAT between my internal VPNs and LANs.  So even that is simpler the new way. I do think that I misconfigured the outbound NATs and somehow that affected the original issue, but I can't say for sure. Thanks, Miki

The beauty of OpenVPN, is that its an application level solution, so if it helps to visualise it, think of it as you would think of a web server application or a telnet application. In this way, your proposed scenario is perfectly suitable for OpenVPN (and not for other VPN technologies). This is unlike the IPSec or PPTP VPNs on your ASA (where I think you might be coming from, from reading your comments) which require specific lower level protocols to work (OSI level 3), and which need direct access to the WAN interface and no playing around with NATs and firewall transversals (it IS possible but its not natural for these VPN technologies).

You might be interested in http://en.wikipedia.org/wiki/Cloudvpn. It's apparently abandoned, but I played with it a few years ago, and it does work.

Hard to believe I miss the force all traffic check box. Thank you!

Firewall rules on the OpenVPN interface determine what traffic is permitted to pass from remote OpenVPN clients/networks through pfSense to other interfaces (like LAN/OPT1.) Try a pass any any to LAN subnet on the OpenVPN firewall rules tab to get it working then clamp it down to specific hosts/ports if desired.

Not even close to enough information provided.