[Support] binhex - rTorrentVPN


Recommended Posts

Hi guys, Im having some issues with this installation.

Fist of all is it possible to disable rutorrent authentication? how? tried setting -e ENABLE_RPC2=no and -e ENABLE_RPC2_AUTH=no to no avail.

 

Now the biggest problem, no matter what i try, my rtorrent crashes (or so i think) in like 2 min intervals, with error: "[24.05.2019 04:09:33] Bad response from server: (500 [error,list]) Link to XMLRPC failed. May be, rTorrent is down?"

Could someone help me? i tried lots of things but am stuck here.. thank you

Link to comment

So, I've been wrestling with this for a while with zero luck. I'm attempting to run the container on an Ubuntu 18.04 host, and with the VPN disabled it works. With the VPN enabled, it appears to never successfully connect.

 

Ubuntu has no tun.ko module; however support for those interfaces is included in the kernel:

$ dmesg | grep tun
[    2.297678] tun: Universal TUN/TAP device driver, 1.6

Basically, what I see is that the OpenVPN starts, but never gets a valid IP address.

2019-05-26T15:15:19.194876122Z [info] OpenVPN started
2019-05-26T15:15:19.194889755Z 
2019-05-26T15:15:19.195350049Z 2019-05-26 11:15:19,195 DEBG 'start-script' stdout output:
2019-05-26T15:15:19.195364298Z [debug] Waiting for valid IP address from tunnel...
2019-05-26T15:15:19.195373706Z 
2019-05-26T15:15:19.195854980Z 2019-05-26 11:15:19,195 DEBG 'start-script' stdout output:
2019-05-26T15:15:19.195870025Z Sun May 26 11:15:19 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]209.58.135.108:443
2019-05-26T15:15:19.195880028Z Sun May 26 11:15:19 2019 UDP link local: (not bound)
2019-05-26T15:15:19.195890919Z Sun May 26 11:15:19 2019 UDP link remote: [AF_INET]209.58.135.108:443
2019-05-26T15:15:19.195906454Z 
2019-05-26T15:15:49.680951014Z 2019-05-26 11:15:49,680 DEBG 'start-script' stdout output:
2019-05-26T15:15:49.680982600Z Sun May 26 11:15:49 2019 [UNDEF] Inactivity timeout (--ping-exit), exiting
2019-05-26T15:15:49.680991231Z 
2019-05-26T15:15:49.681155877Z 2019-05-26 11:15:49,681 DEBG 'start-script' stdout output:
2019-05-26T15:15:49.681192860Z Sun May 26 11:15:49 2019 SIGTERM[soft,ping-exit] received, process exiting

Can anybody provide any help? VPN authentication is via a private key, redacted in the log.

supervisord.log

Link to comment

I'm having huge problems that I have been trying to solve for 2 weeks now. Got some help in Discord from others but nothing we try seems to work.

I have timouts all the time, rutorrent/rtorrent is completely unusable. As soon as I add 1 active torrent, I cant do anything. Not reach the webui, not add another torrent (through sonarr/radarr). And that download takes hours or days to complete. If no torrent is active the webui is still very slow and timeouts.

We have tried customizing my rtorrent config file but nothing works so I went back to the original one. We tried to add memory options and such, no difference.

Server specs:
Motherboard: Supermicro X9DRD-7LN4F
CPU: 2x Intel® Xeon® CPU E5-2670 v2 @ 2.50GHz (Load is around 9-10% atm when I try to fix and/or access rutorrent)
Memory: 64 GiB DDR3 (Ram is only 24% used so its not running out if ram)

Only 280 torrents atm.
Running latest version of the binhex-rtorrentvpn docker, unraid 6.7.0. Have tried to force an update but didnt resolve my issue.

Is there anything else? What specific logs do you need and where are they located?

Link to comment
On 5/26/2019 at 4:42 PM, MCU said:

So, I've been wrestling with this for a while with zero luck. I'm attempting to run the container on an Ubuntu 18.04 host, and with the VPN disabled it works. With the VPN enabled, it appears to never successfully connect.

 

Ubuntu has no tun.ko module; however support for those interfaces is included in the kernel:


$ dmesg | grep tun
[    2.297678] tun: Universal TUN/TAP device driver, 1.6

Basically, what I see is that the OpenVPN starts, but never gets a valid IP address.


2019-05-26T15:15:19.194876122Z [info] OpenVPN started
2019-05-26T15:15:19.194889755Z 
2019-05-26T15:15:19.195350049Z 2019-05-26 11:15:19,195 DEBG 'start-script' stdout output:
2019-05-26T15:15:19.195364298Z [debug] Waiting for valid IP address from tunnel...
2019-05-26T15:15:19.195373706Z 
2019-05-26T15:15:19.195854980Z 2019-05-26 11:15:19,195 DEBG 'start-script' stdout output:
2019-05-26T15:15:19.195870025Z Sun May 26 11:15:19 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]209.58.135.108:443
2019-05-26T15:15:19.195880028Z Sun May 26 11:15:19 2019 UDP link local: (not bound)
2019-05-26T15:15:19.195890919Z Sun May 26 11:15:19 2019 UDP link remote: [AF_INET]209.58.135.108:443
2019-05-26T15:15:19.195906454Z 
2019-05-26T15:15:49.680951014Z 2019-05-26 11:15:49,680 DEBG 'start-script' stdout output:
2019-05-26T15:15:49.680982600Z Sun May 26 11:15:49 2019 [UNDEF] Inactivity timeout (--ping-exit), exiting
2019-05-26T15:15:49.680991231Z 
2019-05-26T15:15:49.681155877Z 2019-05-26 11:15:49,681 DEBG 'start-script' stdout output:
2019-05-26T15:15:49.681192860Z Sun May 26 11:15:49 2019 SIGTERM[soft,ping-exit] received, process exiting

Can anybody provide any help? VPN authentication is via a private key, redacted in the log.

supervisord.log 21.63 kB · 1 download

i would suspect there is something blocking the connection on the host, so check ubuntu firewall, if its not firewall related then my next suspect would be the ovpn remote line is incorrect, or out of date, in short the openvpn client is unable to connect to the vpn endpoint for some reason.

Link to comment

Hello, so I've gotten myself NordVPN since a couple of days, now when I followed spaceinvaderone's guide on how to install it with Deluge it wouldn't download torrents anymore... It would maybe start downloading for a couple of seconds at a VERY slow rate and stop again... It also said Connection error with tracker... I have also tried switching over to ruTorrent VPN and same story.... 

 

The torrents to work, it's got 2000 seeders, also tried downloading it via my own PC with the VPN app running whilst connected to a p2p server and speed was normal and no errors... Has anyone gotten an idea?

Link to comment
2 minutes ago, TristanDK said:

Hello, so I've gotten myself NordVPN since a couple of days, now when I followed spaceinvaderone's guide on how to install it with Deluge it wouldn't download torrents anymore... It would maybe start downloading for a couple of seconds at a VERY slow rate and stop again... It also said Connection error with tracker... I have also tried switching over to ruTorrent VPN and same story.... 

 

The torrents to work, it's got 2000 seeders, also tried downloading it via my own PC with the VPN app running whilst connected to a p2p server and speed was normal and no errors... Has anyone gotten an idea?

check Q6. from the following link:-

https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Link to comment
7 minutes ago, TristanDK said:

And if my provider doesn't support port forwarding it is useless or?...

not useless, but it will be slow, especially on small swarms where you might not be able to connect to many/any peers

Link to comment
28 minutes ago, binhex said:

not useless, but it will be slow, especially on small swarms where you might not be able to connect to many/any peers

We're talking about 50kb/s, whilst I have  200/20Mb/s speeds... Isn't this too slow and is there anything else wrong with my config? Otherwise, guess I'll refund NordVPN and look for another one...

Edited by TristanDK
Link to comment

update: I have refunded my NordVPN, bought PIA for the port forwarding aaaaand, still having this problem... The main problem is that it will lose connection with the tracker every x seconds and thus is not receiving/keeping any peers... I have tried multiple other servers that support port forwarding, and also on my PC I still get normal torrent speeds whilst connected to the same VPN server...

Link to comment
12 minutes ago, TristanDK said:

update: I have refunded my NordVPN, bought PIA for the port forwarding aaaaand, still having this problem... The main problem is that it will lose connection with the tracker every x seconds and thus is not receiving/keeping any peers... I have tried multiple other servers that support port forwarding, and also on my PC I still get normal torrent speeds whilst connected to the same VPN server...

Please follow the procedure in the link below:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Link to comment
3 minutes ago, TristanDK said:

Still speeds between 0.6Kb/s and 50Kb/s...

have you configured rutorrent to write incomplete downloads to /data/<somewhere> ? (ruTorrent Settings/Downloads/Default directory for download:)

Link to comment
15 hours ago, binhex said:

have you configured rutorrent to write incomplete downloads to /data/<somewhere> ? (ruTorrent Settings/Downloads/Default directory for download:)

Yes, I do have this enabled, but like I said I'm having the same issue with Deluge, and as soon as I disable the VPN function speeds go back to normal...

Link to comment
Yes, I do have this enabled, but like I said I'm having the same issue with Deluge, and as soon as I disable the VPN function speeds go back to normal...
Check firewall isn't blocking encrypted traffic, especially if you are using pfsense as this can be quite restrictive out of the box (and rightly so).

Sent from my EML-L29 using Tapatalk

Link to comment
On 5/28/2019 at 11:02 PM, binhex said:

lets take a look at the logs eh, please follow the procedure linked below:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Thank you.

I was on vacation so I haven't had the time until now. I did all the above, but my supervisord.log shows nothing related to this.

I restarted the container with debug=true, and it did work quite fine to add several torrents and also access the webui at the same time. But then after 30 minutes it was back to being unreachable as soon as it did anything else, such as having 1 torrent active.

This has btw never worked before, restarting the container or force updating it have never made this work in the start, as it did now. So that was new.

But I downloaded the log, and the latest 30 mins is only watchdog, confirming that the IP is my public VPN IP. Nothing else.
 

2019-06-01 18:08:52,935 DEBG 'watchdog-script' stdout output:
[debug] External IP address from tunnel is 'X.X.X.X'

 

Link to comment
On ‎5‎/‎28‎/‎2019 at 4:59 PM, binhex said:

i would suspect there is something blocking the connection on the host, so check ubuntu firewall, if its not firewall related then my next suspect would be the ovpn remote line is incorrect, or out of date, in short the openvpn client is unable to connect to the vpn endpoint for some reason.

This was enough for me to figure it out.

 

To document for others using VPN Unlimited, the configuration files you get from them don't specify VPN_PORT, and the container complains loudly. I, like an idiot, put in 443. That didn't work, and trying to start the configuration outside of the docker with and without that port confirmed it WAS the remote line. Setting the VPN_PORT in the config file to 1194 made everything right as rain. (Note, VPN Unlimited doesn't document available ports on their website, but I did find someone else who did; 443 was listed as supported, but clearly wasn't working. The default VPN port of 1194 did.)

Thanks, binhex. Donation incoming.

  • Like 1
Link to comment
On 6/1/2019 at 12:11 PM, binhex said:

Check firewall isn't blocking encrypted traffic, especially if you are using pfsense as this can be quite restrictive out of the box (and rightly so).

Sent from my EML-L29 using Tapatalk
 

Using default ISP's router/modem combo since they don't offer modem only to the public... I called their customer service as well as did some research and can confirm it is not blocking encrypted traffic... 

Link to comment
15 hours ago, TristanDK said:

Using default ISP's router/modem combo since they don't offer modem only to the public... I called their customer service as well as did some research and can confirm it is not blocking encrypted traffic... 

ok last thing you can try, if this doesnt work then im officially out of ideas :-).

 

download this ovpn zip linked below, unzip and copy the endpoint location you want to /config/openvpn/ and rename the old one, just slap a .old extension on it so it wont get picked up, and then restart the container.

https://www.privateinternetaccess.com/openvpn/openvpn-ip-tcp.zip

Link to comment
6 hours ago, binhex said:

ok last thing you can try, if this doesnt work then im officially out of ideas :-).

  

download this ovpn zip linked below, unzip and copy the endpoint location you want to /config/openvpn/ and rename the old one, just slap a .old extension on it so it wont get picked up, and then restart the container.

 https://www.privateinternetaccess.com/openvpn/openvpn-ip-tcp.zip

How is this different from a 'normal' setup?... I'm sure the problem is something simple af, ughh. Thanks for your patience tho!

 

On an ubuntu iso download with 190 peers I get 0.52Kb/s as soon as I disable the vpn feature speed goes back to normal. Log files indicate that the docker IS getting an ip address from the VPN and the incoming port is being changed inside of the deluge settings. I haven't gotten any luck checking if the port actually gets forwarded or not, but still I don't think that speeds would be this slow, especially not on a linux iso with 190 available peers....

Edited by TristanDK
Link to comment
1 minute ago, TristanDK said:

How is this different from a 'normal' setup?... I'm sure the problem is something simple af, ughh. Thanks for your patience tho!

its a restricted ip specific endpoint on port 443, i want to be sure its not your isp screwing with it, i know you said they dont but it wouldnt be the first time ive seen this sort of thing.

 

 

Link to comment
2 minutes ago, binhex said:

its a restricted ip specific endpoint on port 443, i want to be sure its not your isp screwing with it, i know you said they dont but it wouldnt be the first time ive seen this sort of thing.

 

 

Okay, but I still don't see how this is different from a normal installation (like shown in spaceinvader's video). Yea most of the time those people in the call centers don't know sh*** about their products...

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