[Support] binhex - rTorrentVPN


Recommended Posts

16 hours ago, Spies said:

Is it possible to configure this container to work without a VPN? Or can I just install the non-VPN container and copy the appdata folders over to save everthing I'm seeding?

If VPN = no doesn't work for you then you are better off with a non-VPN docker (e.g. LSIO rutorrent).

I would imagine it's somewhat trivial to install a test run of the LSIO docker and match + cp appdata over.

 

Link to comment
#####################################################################
#
# The Seedbox From Scratch Script
#   ---> https://github.com/thevisad/
#
#
## See Readme.md for License ###

max_downloads_global = 0
max_uploads_global = 0
min_peers = 50
max_peers = 200
min_peers_seed = 50
max_peers_seed = 200

max_uploads = 50

download_rate = 0
upload_rate = 0

trackers.use_udp.set = yes
encryption = allow_incoming,try_outgoing,enable_retry
network.max_open_files.set = 2500
#network.max_open_sockets.set = 1536
network.http.max_open.set = 256
network.send_buffer.size.set = 1M
network.receive_buffer.size.set = 1M
dht = auto
protocol.pex.set = yes

check_hash = no
pieces.preload.type.set = 1
max_memory_usage = 3500M



throttle.global_down.max_rate.set_kb = 6400
throttle.global_up.max_rate.set_kb = 1024


# Default directory to save the downloaded torrents.
#
execute = {/bin/bash,-c,mkdir -p /downloads/incoming}
directory.default.set = /downloads/incoming/

# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
#
execute = {/bin/bash,-c,mkdir -p /config/rtorrent/session}
session.path.set = /config/rtorrent/session/


network.port_random.set = no
network.port_range.set = 51413-51413

# Disable check for SSL cert for tracker
#
network.http.ssl_verify_peer.set = 0

dht.mode.set = auto

# UDP port to use for DHT.
#
dht.port.set = 6881

# Enable peer exchange (for torrents not marked private)
#
protocol.pex.set = yes

# Set downlad list layout style. ("full", "compact")
#
#ui.torrent_list.layout.set = "full"

# SCGI Connectivity (for alternative rtorrent interfaces, XMLRPC)
#
# Use a IP socket with scgi_port, or a Unix socket with scgi_local.
# schedule can be used to set permissions on the unix socket.
#
scgi_port = 0.0.0.0:5000
#scgi_local = /home/user/rtorrent/rpc.socket
#schedule = scgi_permission,0,0,"execute.nothrow=chmod,\"g+w,o=\",/home/user/rtorrent/rpc.socket"

# Initialise ruTorrent plugins (required for rss and scheduler plugins) on startup
# (normally triggered by a browser opening the web ui).
#
# The command below in practice does NOT always trigger (possible race condition?) and thus
# the same command has been added to the script /home/nobody/initplugins.sh in order to
# attempt to ensure all plugins are initialised.
#
execute = {/bin/bash,-c,/usr/bin/sleep 10s && /usr/bin/php /usr/share/webapps/rutorrent/php/initplugins.php admin &}

 

Link to comment
3 minutes ago, Spies said:

network.port_range.set = 51413-51413

ok that looks set correctly, can you see port 51413 shown in rutorrent webui in settings/connection/port used for incoming connections? 

also can you go to unraid webui/docker/ left click rtorrentvpn select edit and then screenshot that screen and post here.

Link to comment
4 minutes ago, binhex said:

ok that looks set correctly, can you see port 51413 shown in rutorrent webui in settings/connection/port used for incoming connections? 

also can you go to unraid webui/docker/ left click rtorrentvpn select edit and then screenshot that screen and post here.

rutorrent does show that in settings yes.

 

Here are the screenshots from my docker.

2.png

1.png

Link to comment
On 9/13/2020 at 12:31 AM, cardo said:

Has anyone who switched to Mullvad get port forwarding to work?  I know the strict port forward is ignored if don’t have PIA, but I’ve added a port forward for my account over at Mullvad and have gone into ruTorrent front end and choose settings > connection > port used for incoming connections and set it to the port and even tried 1234-1234 where 1234 is the real port number. It doesn’t do anything for me. The status icon at the bottom is still a red exclamation mark. 
 

I have a gigabit connection and without port forwarding I get about 60MB/sec on a well seeded torrent, I used to get as high as 85MB/sec with PIA and port forwarding enabled. 
 

EDIT: I should add I copied the rtorrent.rc file to .rtorrent.rc with the ports specified from Mullvad and the port status still is red. :(

I’ve also manually forwarded the port in my firewall and added two port entries in the container one for TCP and another for UDP and it still fails both from rTorrent’s port status as well as the external tester. 

Link to comment

It looks like PIA is requiring their new next gen servers to work with the API to allow port forwarding. 

 

I've done a bunch of testing, it looks like the API is not responding on the non-nextgen VPN servers currently, and it also looks like API is not setup on the next gen servers at all.

 

Anyone come up with a work around for this?  Everything I've tried has failed.

Edited by LiQiuD
Link to comment

Ditto - I can't get this container to work with PIA at all any more. Is anyone else having more luck? I'm a little confused on the old API/new API, net gen server etc - I just know it's not working. Will there be an update so that the container works with PIA? If not anyone know of alternatives?

 

thanks!

Link to comment
10 hours ago, LiQiuD said:

It looks like PIA is requiring their new next gen servers to work with the API to allow port forwarding. 

 

I've done a bunch of testing, it looks like the API is not responding on the non-nextgen VPN servers currently, and it also looks like API is not setup on the next gen servers at all.

 

Anyone come up with a work around for this?  Everything I've tried has failed.

 

32 minutes ago, kirk8999 said:

Ditto - I can't get this container to work with PIA at all any more. Is anyone else having more luck? I'm a little confused on the old API/new API, net gen server etc - I just know it's not working. Will there be an update so that the container works with PIA? If not anyone know of alternatives?

 

thanks!

I got port forwarding working with the Spainish server (one of the old ones), before that I could make it to work with servers in Switzerland but it no longer works for me.

Unfortunately, until PIA stabilises old servers or provide APIs to port forward on next-gen servers there's no much that can be done other than server hopping and praying. :(

Edited by Cat_Seeder
Link to comment
1 hour ago, tooviral said:

It may take some time for it to show open, took a day or two for me.

Can you provide more information about how you configured the container/router, because I set this up 4-5 days ago and it is still failing for me.

 

Here were my steps:

 

1. Set up the port forward on Mullvad. 
2. set up a port forwarding rule on my router from anywhere to my private IP and port I’ve set up on Mullvad.  It is set for both TCP/UDP.

3. Created two port entries in the container, one for UDP and one for TCP and specified the port on Mullvad and my router’s port forward rule. 
4. Edited the .torrent.rc file and specified the port like this: network.port_range.set = xxxx-xxxx where xxxx is the port number.

5. When starting the container and going to Settings > Connection > Port used for income connection shows my port. Yet the status still shows the exclamation mark with the port being closed. 

Link to comment

OK guys, multi remote endpoint support is now in for this image please pull down the new image (this change will be rolled out to all my vpn images shortly).

 

What this means is that the image will now loop through the entire list, for example, pia port forward enabled endpoints, all you need to do is edit your ovpn config file and add the remote endpoints at the top and sort into the order you want them to be tried, an example pia ovpn file is below (mine):-

remote ca-toronto.privateinternetaccess.com 1198 udp
remote ca-montreal.privateinternetaccess.com 1198 udp
remote ca-vancouver.privateinternetaccess.com 1198 udp
remote de-berlin.privateinternetaccess.com 1198 udp
remote de-frankfurt.privateinternetaccess.com 1198 udp
remote france.privateinternetaccess.com 1198 udp
remote czech.privateinternetaccess.com 1198 udp
remote spain.privateinternetaccess.com 1198 udp
remote ro.privateinternetaccess.com 1198 udp
client
dev tun
resolv-retry infinite
nobind
persist-key
# -----faster GCM-----
cipher aes-128-gcm
auth sha256
ncp-disable
# -----faster GCM-----
tls-client
remote-cert-tls server
auth-user-pass credentials.conf
comp-lzo
verb 1
crl-verify crl.rsa.2048.pem
ca ca.rsa.2048.crt
disable-occ

 

I did look at multi ovpn file support, but this is easier to do and as openvpn supports multi remote lines, it felt like the most logical approach.

 

note:- Due to ns lookup for all remote lines, and potential failure and subsequent try of the next remote line, time to initialisation of the app may take longer.

 

p.s. I dont want to talk about how difficult this was to shoe horn in, i need to lie down in a dark room now and not think about bash for a while :-), any issues let me know!.

  • Like 1
  • Thanks 7
  • Haha 1
Link to comment

Has something changed recently as my VPN connection seems to be failing suddenly?

The connection to my VPN provider is timing out for some reason, I haven't changed credentials or anything recently, except now that I started troubleshooting this by pulling down new config files and certs from the provider.

 

There doesn't seem to be anything wrong with the IP that the openvpn client is trying to connect to, I tried pinging it from inside the container and there is a response. I also tried using the same .ovpn file from my deluge setup (binhex/arch-delugevpn) which works just fine, but the rtorrent container fails to connect with the same configuration.

 

I am running watchtower on my server where rtorrent is running, so it would have pulled the latest image automatically, is it possible that a something broke with a recently pushed image?

 

NOTE: I reverted to image v3.10-01 and the VPN connects successfully, there is indeed something wrong with the 'latest' tag.

 

In the beginning the connection acually results in a TCP connection error:

2020-09-18 22:36:44,887 DEBG 'start-script' stdout output:
Fri Sep 18 22:36:44 2020 Socket Buffers: R=[131072->131072] S=[16384->16384]
Fri Sep 18 22:36:44 2020 Attempting to establish TCP connection with [AF_INET]<IP>:443 [nonblock]

2020-09-18 22:37:16,891 DEBG 'start-script' stdout output:
Fri Sep 18 22:37:16 2020 TCP: connect to [AF_INET]<IP>:443 failed: Connection timed out

Then the process just loops with this over and over:

2020-09-18 22:38:18,195 DEBG 'start-script' stdout output:
Fri Sep 18 22:38:18 2020 [UNDEF] Inactivity timeout (--ping-restart), restarting
Fri Sep 18 22:38:18 2020 SIGHUP[soft,ping-restart] received, process restarting
Fri Sep 18 22:38:18 2020 WARNING: file 'ovpn-tls.key' is group or others accessible
Fri Sep 18 22:38:18 2020 WARNING: file 'credentials.conf' is group or others accessible
Fri Sep 18 22:38:18 2020 OpenVPN 2.4.9 [git:makepkg/9b0dafca6c50b8bb+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 20 2020
Fri Sep 18 22:38:18 2020 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
Fri Sep 18 22:38:18 2020 Restart pause, 2 second(s)

2020-09-18 22:38:20,195 DEBG 'start-script' stdout output:
Fri Sep 18 22:38:20 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2020-09-18 22:38:20,196 DEBG 'start-script' stdout output:
Fri Sep 18 22:38:20 2020 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 18 22:38:20 2020 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

2020-09-18 22:38:20,196 DEBG 'start-script' stdout output:
Fri Sep 18 22:38:20 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]<IP>:443
Fri Sep 18 22:38:20 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 18 22:38:20 2020 UDP link local: (not bound)
Fri Sep 18 22:38:20 2020 UDP link remote: [AF_INET]<IP>:443

 

Link to comment
On 9/16/2020 at 8:33 PM, cardo said:

Can you provide more information about how you configured the container/router, because I set this up 4-5 days ago and it is still failing for me.

 

Here were my steps:

 

1. Set up the port forward on Mullvad. 
2. set up a port forwarding rule on my router from anywhere to my private IP and port I’ve set up on Mullvad.  It is set for both TCP/UDP.

3. Created two port entries in the container, one for UDP and one for TCP and specified the port on Mullvad and my router’s port forward rule. 
4. Edited the .torrent.rc file and specified the port like this: network.port_range.set = xxxx-xxxx where xxxx is the port number.

5. When starting the container and going to Settings > Connection > Port used for income connection shows my port. Yet the status still shows the exclamation mark with the port being closed. 

All I did was

 

1. Set up the port forward on Mullvad. 

2. Edited the .torrent.rc file and specified the port like this: network.port_range.set = xxxx-xxxx where xxxx is the port number and set "network.port_random.set = no"

 

and worked

Link to comment
1 hour ago, tooviral said:

All I did was

 

1. Set up the port forward on Mullvad. 

2. Edited the .torrent.rc file and specified the port like this: network.port_range.set = xxxx-xxxx where xxxx is the port number and set "network.port_random.set = no"

 

and worked

So, the port status shows open in the status bar?

Link to comment
11 hours ago, binhex said:

OK guys, multi remote endpoint support is now in for this image please pull down the new image (this change will be rolled out to all my vpn images shortly).

 

What this means is that the image will now loop through the entire list, for example, pia port forward enabled endpoints, all you need to do is edit your ovpn config file and add the remote endpoints at the top and sort into the order you want them to be tried, an example pia ovpn file is below (mine):-


# -----faster GCM-----
auth sha256

 

was that built off the default pia files? looking at mine, the gcm and auth are different (quickly compared so probably more differences).

Link to comment
11 hours ago, binhex said:

OK guys, multi remote endpoint support is now in for this image please pull down the new image (this change will be rolled out to all my vpn images shortly).

 

What this means is that the image will now loop through the entire list, for example, pia port forward enabled endpoints, all you need to do is edit your ovpn config file and add the remote endpoints at the top and sort into the order you want them to be tried, an example pia ovpn file is below (mine):-


remote ca-toronto.privateinternetaccess.com 1198 udp
remote ca-montreal.privateinternetaccess.com 1198 udp
remote ca-vancouver.privateinternetaccess.com 1198 udp
remote de-berlin.privateinternetaccess.com 1198 udp
remote de-frankfurt.privateinternetaccess.com 1198 udp
remote france.privateinternetaccess.com 1198 udp
remote czech.privateinternetaccess.com 1198 udp
remote spain.privateinternetaccess.com 1198 udp
remote ro.privateinternetaccess.com 1198 udp
client
dev tun
resolv-retry infinite
nobind
persist-key
# -----faster GCM-----
cipher aes-128-gcm
auth sha256
ncp-disable
# -----faster GCM-----
tls-client
remote-cert-tls server
auth-user-pass credentials.conf
comp-lzo
verb 1
crl-verify crl.rsa.2048.pem
ca ca.rsa.2048.crt
disable-occ

 

I did look at multi ovpn file support, but this is easier to do and as openvpn supports multi remote lines, it felt like the most logical approach.

 

note:- Due to ns lookup for all remote lines, and potential failure and subsequent try of the next remote line, time to initialisation of the app may take longer.

 

p.s. I dont want to talk about how difficult this was to shoe horn in, i need to lie down in a dark room now and not think about bash for a while :-), any issues let me know!.

Haha i'm looking at the code https://github.com/binhex/arch-rtorrentvpn/commit/4aeb0bb40542d8450bfb21dcc1c16978c6640ff0

I see what you mean, this would have been much easier with a real programming language. Python would have worked perfectly for this. Anyway, thanks for your help. I managed to get it working a week ago and it hasn't disconnected since so I plan on updating when it goes down, thank!

  • Thanks 1
Link to comment
Has something changed recently as my VPN connection seems to be failing suddenly?

The connection to my VPN provider is timing out for some reason, I haven't changed credentials or anything recently, except now that I started troubleshooting this by pulling down new config files and certs from the provider.

 

There doesn't seem to be anything wrong with the IP that the openvpn client is trying to connect to, I tried pinging it from inside the container and there is a response. I also tried using the same .ovpn file from my deluge setup (binhex/arch-delugevpn) which works just fine, but the rtorrent container fails to connect with the same configuration.

 

I am running watchtower on my server where rtorrent is running, so it would have pulled the latest image automatically, is it possible that a something broke with a recently pushed image?

 

NOTE: I reverted to image v3.10-01 and the VPN connects successfully, there is indeed something wrong with the 'latest' tag.

 

In the beginning the connection acually results in a TCP connection error:

2020-09-18 22:36:44,887 DEBG 'start-script' stdout output:Fri Sep 18 22:36:44 2020 Socket Buffers: R=[131072->131072] S=[16384->16384]Fri Sep 18 22:36:44 2020 Attempting to establish TCP connection with [AF_INET]:443 [nonblock]2020-09-18 22:37:16,891 DEBG 'start-script' stdout output:Fri Sep 18 22:37:16 2020 TCP: connect to [AF_INET]:443 failed: Connection timed out

Then the process just loops with this over and over:

 

2020-09-18 22:38:18,195 DEBG 'start-script' stdout output:Fri Sep 18 22:38:18 2020 [uNDEF] Inactivity timeout (--ping-restart), restartingFri Sep 18 22:38:18 2020 SIGHUP[soft,ping-restart] received, process restartingFri Sep 18 22:38:18 2020 WARNING: file 'ovpn-tls.key' is group or others accessibleFri Sep 18 22:38:18 2020 WARNING: file 'credentials.conf' is group or others accessibleFri Sep 18 22:38:18 2020 OpenVPN 2.4.9 [git:makepkg/9b0dafca6c50b8bb+] x86_64-pc-linux-gnu [sSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 20 2020Fri Sep 18 22:38:18 2020 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10Fri Sep 18 22:38:18 2020 Restart pause, 2 second(s)2020-09-18 22:38:20,195 DEBG 'start-script' stdout output:Fri Sep 18 22:38:20 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts2020-09-18 22:38:20,196 DEBG 'start-script' stdout output:Fri Sep 18 22:38:20 2020 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authenticationFri Sep 18 22:38:20 2020 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication2020-09-18 22:38:20,196 DEBG 'start-script' stdout output:Fri Sep 18 22:38:20 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]:443Fri Sep 18 22:38:20 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]Fri Sep 18 22:38:20 2020 UDP link local: (not bound)Fri Sep 18 22:38:20 2020 UDP link remote: [AF_INET]:443

 

 

Is the 'remote' line in your ovpn file an IP address or a hostname? I'm assuming it's a single remote line right?

 

Sent from my CLT-L09 using Tapatalk

 

 

 

Link to comment
  • binhex locked this topic
Guest
This topic is now closed to further replies.