OpenVPN connecting to a server via a Tor (SOCKS) proxy - error: "timeout expired" and "Inactivity timeout"" in Linux

Question

I'm trying to connect to an OpenVPN server through Tor Socks Proxy.

When I try to connect to the VPN sometimes I receive this error message "Recv_socks_reply: TCP Port Read Timeout expired" and OpenVPN tries to re-establish the connection.

Other times instead the connection to the VPN happens successfully, but as soon as I try to connect to a website the connection falls by giving me "Inactivity timeout (--ping-restart), restarting".

Using the same .ovpn and the same torrc on Windows everything works properly.

I use OpenVPN version 2.4.3 on Linux and 2.4.4 on Windows.

Log (Recv_socks_reply: TCP Port Read Timeout expired):

Sat Oct 21 12:31:31 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:9050
Sat Oct 21 12:31:31 2017 Socket Buffers: R=[87380->87380] S=[16384->16384]
Sat Oct 21 12:31:31 2017 Attempting to establish TCP connection with [AF_INET]127.0.0.1:9050 [nonblock]
Sat Oct 21 12:31:31 2017 TCP connection established with [AF_INET]127.0.0.1:9050
Sat Oct 21 12:31:36 2017 recv_socks_reply: TCP port read timeout expired: Operation now in progress (errno=115)
Sat Oct 21 12:31:36 2017 SIGUSR1[soft,init_instance] received, process restarting
Sat Oct 21 12:31:36 2017 Restart pause, 5 second(s)

Log (Inactivity timeout (--ping-restart), restarting):

Sat Oct 21 12:25:30 2017 DEPRECATED OPTION: http-proxy-retry and socks-proxy-retry: In OpenVPN 2.4 proxy connection retries are handled like regular connections. Use connect-retry-max 1 to get a similar behavior as before.
Sat Oct 21 12:25:30 2017 OpenVPN 2.4.3 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun 30 2017
Sat Oct 21 12:25:30 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Sat Oct 21 12:25:30 2017 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Oct 21 12:25:30 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:9050
Sat Oct 21 12:25:30 2017 Socket Buffers: R=[87380->87380] S=[16384->16384]
Sat Oct 21 12:25:30 2017 Attempting to establish TCP connection with [AF_INET]127.0.0.1:9050 [nonblock]
Sat Oct 21 12:25:30 2017 TCP connection established with [AF_INET]127.0.0.1:9050
Sat Oct 21 12:25:31 2017 TCP_CLIENT link local: (not bound)
Sat Oct 21 12:25:31 2017 TCP_CLIENT link remote: [AF_INET]127.0.0.1:9050
Sat Oct 21 12:25:31 2017 TLS: Initial packet from [AF_INET]127.0.0.1:9050, sid=03e99185 49df78b9
Sat Oct 21 12:25:32 2017 VERIFY OK: depth=2, C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
Sat Oct 21 12:25:32 2017 VERIFY OK: depth=1, C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
Sat Oct 21 12:25:32 2017 VERIFY OK: depth=0, OU=Domain Control Validated, OU=PositiveSSL Wildcard, CN=*.opengw.net
Sat Oct 21 12:25:33 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sat Oct 21 12:25:33 2017 [*.opengw.net] Peer Connection Initiated with [AF_INET]127.0.0.1:9050
Sat Oct 21 12:25:34 2017 SENT CONTROL [*.opengw.net]: 'PUSH_REQUEST' (status=1)
Sat Oct 21 12:25:34 2017 PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10,ifconfig 10.211.1.13 10.211.1.14,dhcp-option DNS 10.211.254.254,dhcp-option DNS 8.8.8.8,route-gateway 10.211.1.14,redirect-gateway def1'
Sat Oct 21 12:25:34 2017 OPTIONS IMPORT: timers and/or timeouts modified
Sat Oct 21 12:25:34 2017 OPTIONS IMPORT: --ifconfig/up options modified
Sat Oct 21 12:25:34 2017 OPTIONS IMPORT: route options modified
Sat Oct 21 12:25:34 2017 OPTIONS IMPORT: route-related options modified
Sat Oct 21 12:25:34 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Oct 21 12:25:34 2017 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sat Oct 21 12:25:34 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Oct 21 12:25:34 2017 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sat Oct 21 12:25:34 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Oct 21 12:25:34 2017 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlan0 HWADDR=AAAAAA
Sat Oct 21 12:25:35 2017 TUN/TAP device tun0 opened
Sat Oct 21 12:25:35 2017 TUN/TAP TX queue length set to 100
Sat Oct 21 12:25:35 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Oct 21 12:25:35 2017 /sbin/ip link set dev tun0 up mtu 1500
Sat Oct 21 12:25:35 2017 /sbin/ip addr add dev tun0 local 10.211.1.13 peer 10.211.1.14
Sat Oct 21 12:25:36 2017 /sbin/ip route add 127.0.0.1/32 via 192.168.1.1
Sat Oct 21 12:25:36 2017 /sbin/ip route add 0.0.0.0/1 via 10.211.1.14
Sat Oct 21 12:25:36 2017 /sbin/ip route add 128.0.0.0/1 via 10.211.1.14
Sat Oct 21 12:25:36 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Oct 21 12:25:36 2017 Initialization Sequence Completed
Sat Oct 21 12:25:46 2017 [*.opengw.net] Inactivity timeout (--ping-restart), restarting
Sat Oct 21 12:25:46 2017 SIGUSR1[soft,ping-restart] received, process restarting
Sat Oct 21 12:25:46 2017 Restart pause, 5 second(s)

Here is the .ovpn file:

###############################################################################
# OpenVPN 2.0 Sample Configuration File
# for PacketiX VPN / SoftEther VPN Server
# 
# !!! AUTO-GENERATED BY SOFTETHER VPN SERVER MANAGEMENT TOOL !!!
# 
# !!! YOU HAVE TO REVIEW IT BEFORE USE AND MODIFY IT AS NECESSARY !!!
# 
# This configuration file is auto-generated. You might use this config file
# in order to connect to the PacketiX VPN / SoftEther VPN Server.
# However, before you try it, you should review the descriptions of the file
# to determine the necessity to modify to suitable for your real environment.
# If necessary, you have to modify a little adequately on the file.
# For example, the IP address or the hostname as a destination VPN Server
# should be confirmed.
# 
# Note that to use OpenVPN 2.0, you have to put the certification file of
# the destination VPN Server on the OpenVPN Client computer when you use this
# config file. Please refer the below descriptions carefully.


###############################################################################
# Specify the type of the layer of the VPN connection.
# 
# To connect to the VPN Server as a "Remote-Access VPN Client PC",
#  specify 'dev tun'. (Layer-3 IP Routing Mode)
#
# To connect to the VPN Server as a bridging equipment of "Site-to-Site VPN",
#  specify 'dev tap'. (Layer-2 Ethernet Bridgine Mode)

dev tun


###############################################################################
# Specify the underlying protocol beyond the Internet.
# Note that this setting must be correspond with the listening setting on
# the VPN Server.
# 
# Specify either 'proto tcp' or 'proto udp'.

proto tcp


###############################################################################
# The destination hostname / IP address, and port number of
# the target VPN Server.
# 
# You have to specify as 'remote <HOSTNAME> <PORT>'. You can also
# specify the IP address instead of the hostname.
# 
# Note that the auto-generated below hostname are a "auto-detected
# IP address" of the VPN Server. You have to confirm the correctness
# beforehand.
# 
# When you want to connect to the VPN Server by using TCP protocol,
# the port number of the destination TCP port should be same as one of
# the available TCP listeners on the VPN Server.
# 
# When you use UDP protocol, the port number must same as the configuration
# setting of "OpenVPN Server Compatible Function" on the VPN Server.

remote vpn118495111.opengw.net 1902


###############################################################################
# The HTTP/HTTPS proxy setting.
# 
# Only if you have to use the Internet via a proxy, uncomment the below
# two lines and specify the proxy address and the port number.
# In the case of using proxy-authentication, refer the OpenVPN manual.

;http-proxy-retry
;http-proxy [proxy server] [proxy port]


###############################################################################
# The encryption and authentication algorithm.
# 
# Default setting is good. Modify it as you prefer.
# When you specify an unsupported algorithm, the error will occur.
# 
# The supported algorithms are as follows:
#  cipher: [NULL-CIPHER] NULL AES-128-CBC AES-192-CBC AES-256-CBC BF-CBC
#          CAST-CBC CAST5-CBC DES-CBC DES-EDE-CBC DES-EDE3-CBC DESX-CBC
#          RC2-40-CBC RC2-64-CBC RC2-CBC
#  auth:   SHA SHA1 MD5 MD4 RMD160

cipher AES-128-CBC
auth SHA1


###############################################################################
# Other parameters necessary to connect to the VPN Server.
# 
# It is not recommended to modify it unless you have a particular need.

resolv-retry infinite
nobind
persist-key
persist-tun
client
verb 3
#auth-user-pass


###############################################################################
# The certificate file of the destination VPN Server.
# 
# The CA certificate file is embedded in the inline format.
# You can replace this CA contents if necessary.
# Please note that if the server certificate is not a self-signed, you have to
# specify the signer's root certificate (CA) here.

<ca>
....
</ca>


###############################################################################
# The client certificate file (dummy).
# 
# In some implementations of OpenVPN Client software
# (for example: OpenVPN Client for iOS),
# a pair of client certificate and private key must be included on the
# configuration file due to the limitation of the client.
# So this sample configuration file has a dummy pair of client certificate
# and private key as follows.

<cert>
...
</cert>

<key>
...
</key>

socks-proxy-retry
socks-proxy 127.0.0.1 9050

Here is the torrc file:

SocksPort 127.0.0.1:9050 PreferSOCKSNoAuth
ControlPort 9051
CookieAuthentication 1

Answer 1

I have tested this kind of thing successfully before in Linux. First of all, I'd suggest isolating the Tor and VPN applications to avoid the issue that cacahuatl mentions, at least for initial testing. This is also addressed in the link that I provide below. In other words, you can run Tor on one (virtual/physical) machine with two Ethernet interfaces #1 and #2. The WAN is connected to iface #1, and the SOCKS server runs on iface #2. The second machine runs TUN2SOCKS and OpenVPN, and sends SOCKS traffic from its iface #3 to iface #2. A fourth interface iface #4 can be used to route traffic from a third machine through the VPN. You'll have to set up the various routing tables and enable IPV4 forwarding in sysctl for the VPN system (for forwarding traffic from iface #4 to the VPN). Here is a tutorial on using TUN2SOCKS with Tor:

https://github.com/ambrop72/badvpn/wiki/Tun2socks

If you want to go one better, then Tor connects via a bridge, and iface #1 connects to the WAN through a packet filter (with only the bridge white-listed). This blocks all outside-the-Tor-tunnel traffic.

With that kind of setup I was able to pass all sorts of traffic successfully end-to-end, UDP, ICMP, etc., not just TCP.

Answer 2

You should force Tor to use a specific network interface.

This can be achieved by using cgroups and some iptables rules, but there is a simpler way: https://gist.github.com/kriswebdev/a8d291936fe4299fb17d3744497b1170

This script do the trick.

Answer 3

You need to utilize LongLivingPorts - just copy the default values and add your ports to the list! In your case - the remote side vpn server port you're using in your ovpn config. Also - keep it in mind - enforce all bindings by ip:port pair in Tor and other applications to avoid data leaks.