How do I configure OpenVPN to wait for high-latency SOCKS proxies?

mirimir · Nov 8, 2013, 2:34 AM

I'm experimenting with OpenVPN connections routed through Tor, using pairs of Tor gateway and OpenVPN-hosting VMs. On the OpenVPN-server side, server link local ports are forwarded to Tor hidden-service ports on the associated gateway VM. On the OpenVPN-client side, clients connect through socks proxies on the associated Tor gateway VM.

The above setup works with Debian 7 as Tor gateway and OpenVPN-hosting VMs (using Whonix). It also works with pfSense 2.03 as both Tor gateway and OpenVPN-hosting VMs on the OpenVPN-client side, and Debian 7 VMs on the OpenVPN-server side. Server-client ping in both cases is about 1200 msec.

However, the above setup does not work using pfSense 2.03 as both Tor gateway and OpenVPN-hosting VMs on the OpenVPN-server side, and either Debian 7 or pfSense 2.03 as Tor gateway and OpenVPN-hosting VMs on the OpenVPN-client side. The problem is that OpenVPN server isn't waiting long enough for high-latency Tor SOCKS proxies. For both clients, I see:

TCP connection established with [AF_INET]192.168.0.10:9152
recv_socks_reply: TCP port read timeout expired: Operation now in progress (error ...)

I was initially using pfSense 2.03, which has OpenVPN 2.2.2. Searching "TCP port read timeout expired", I found posts suggesting that this is a known bug in OpenVPN 2.2.2. And so I switched to pfSense 2.1 (with OpenVPN 2.3.2) as the OpenVPN-hosting VM on the OpenVPN-server side. But I see the same connection error, with either Debian 7 or pfSense 2.03 VMs on the OpenVPN-client side. Debian 7, by the way, also has OpenVPN 2.3.2, so the issue seems specific to pfSense.

How do I configure OpenVPN in pfSense to wait for high-latency SOCKS proxies?

Edit: Adding "tls-timeout 120" to both server and client didn't help.

mirimir · Nov 13, 2013, 4:23 AM

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.