I'm experimenting with OpenVPN connections routed through Tor, using pairs of Tor gateway and OpenVPN-hosting VMs. On the server side, link local ports are forwarded to Tor hidden-service ports on the associated gateway VM. On the client side, OpenVPN connects through socks proxies on the associated Tor gateway VM.
The above setup works using Debian 7 for all Tor gateway and OpenVPN-hosting VMs. I'm using Whonix, which has been updated to OpenVPN 2.3.2 (built on 2013-09-12). Server-client ping is about 1200 msec.
However, the setup does not work using pfSense 2.1 as Tor gateway and OpenVPN-hosting VMs on the server side. pfSense 2.1 also has OpenVPN 2.3.2 (built on 2013-07-24). For both Debian and pfSense 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 ...)
This is the same error reported in Debian bug #657964 for openvpn version 2.2.1-3: "openvpn: Can't connect to a VPN using SOCKS proxy". It's also been reported in OpenVPN bug #328 for openvpn version 2.3.2: "openvpn client gives up instead of retrying when proxy server is slow".
However, this may not be the same bug. The problem here may be latency in forwarding OpenVPN server ports through Tor hidden services, rather than latency in Tor SOCKS proxies on the client side. Or it may be both.
In any case, I find that OpenVPN 2.3.2 servers fail with this client error in pfSense 2.1, but not in Debian 7. Perhaps the latest package in the Debian 7 repository includes bug fixes that were issued since the pfSense 2.1 build.
How can I configure OpenVPN to wait for slow SOCKS proxies?