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 (using [url=https://www.whonix.org/wiki/Main_Page]Whonix[/url]). It also works with pfSense 2.03 as Tor gateway and OpenVPN-hosting VMs on the client side, and Debian 7 VMs on the server side. Server-client ping in both cases is about 1200 msec. However, the above setup does not work using pfSense 2.03 or 2.1 as Tor gateway and OpenVPN-hosting VMs on the server side, and either Debian 7 or pfSense 2.03 as Tor gateway and OpenVPN-hosting VMs on the client side. The problem is that OpenVPN server in pfSense isn't waiting long enough for high-latency Tor SOCKS proxies. For both clients, I see: [code]TCP connection established with [AF_INET]192.168.0.10:9152 recv_socks_reply: TCP port read timeout expired: Operation now in progress (error ...)[/code] 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 server side. But I see the same connection error, with either Debian 7 or pfSense 2.03 VMs on the client side. This is very similar to [url=https://community.openvpn.net/openvpn/ticket/328]bug #328 "openvpn client gives up instead of retrying when proxy server is slow"[/url]. However, Debian 7 also has OpenVPN 2.3.2, so this issue seems specific to pfSense. But I don't see anything obvious in the server.conf that pfSense generates. Debian 7 has OpenVPN 2.3.2 built on 2013-09-12, whereas the pfSense 2.1 build was 2013-07-24: [code]Debian 7: OpenVPN 2.3.2 i486-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 9 2013 pfSense 2.1: OpenVPN 2.3.2 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] LZO] [eurephia] [MH] [IPv6] built on Jul 24 2013[/code] Might the Debian 7 build include new bug-fixes since the pfSense 2.1 build? How might I configure OpenVPN in pfSense to wait for high-latency SOCKS proxies?

How can I configure OpenVPN to wait for slow SOCKS proxies?

mirimir

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

However, the above setup does not work using pfSense 2.03 or 2.1 as Tor gateway and OpenVPN-hosting VMs on the server side, and either Debian 7 or pfSense 2.03 as Tor gateway and OpenVPN-hosting VMs on the client side. The problem is that OpenVPN server in pfSense 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 server side. But I see the same connection error, with either Debian 7 or pfSense 2.03 VMs on the client side.

This is very similar to bug #328 "openvpn client gives up instead of retrying when proxy server is slow". However, Debian 7 also has OpenVPN 2.3.2, so this issue seems specific to pfSense. But I don't see anything obvious in the server.conf that pfSense generates.

Debian 7 has OpenVPN 2.3.2 built on 2013-09-12, whereas the pfSense 2.1 build was 2013-07-24:

Debian 7: OpenVPN 2.3.2 i486-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep  9 2013
pfSense 2.1: OpenVPN 2.3.2 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] LZO] [eurephia] [MH] [IPv6] built on Jul 24 2013

Might the Debian 7 build include new bug-fixes since the pfSense 2.1 build?

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

mirimir

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.