How do I configure OpenVPN to wait for high-latency SOCKS proxies?
-
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.
-
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.