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.

Is your AD auth happening using RADIUS? It looks like your RADIUS server is passing back an invalid IP to the client, from the output. Or at least one that isn't valid given the server configuration.

Thanks jimp,

Yep. I did some testing.
I haven't been able to set up an OpenVpn. Seems the two Firewall has a too different approach on the subject :-)
Due to my current setup I can't find a common setup. On Endian I'm using Openvpn with PSK and Username/Password credential and seems it's not possible to use them in pfSense.
I tried also IPSEC but while pfSens has an extended set of options, Endian as a lesser support of it.

If someone could say "Yes, I did it and it works!", I'd do more tests but i'm not optimist. So far I didn't found evidence that it could be done.

Thanks - that solved the problem

Thanks for the clarification.
For me the easiest rule to follow is:
If you have more than one instance, assign all instances and don't use the openvpn tab.