• 12
name

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?

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.

  • 0
Reply Report
    • You should also accept this answer so that this question is removed from the unanswered questions queue.

Warm tip !!!

This article is reproduced from Stack Exchange / Stack Overflow, please click

Trending Tags