BrttClne22
-
Posts
24 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by BrttClne22
-
-
I've stayed at 4.3.9 for a while after the 4.4.0 debacle and am finally considering moving to 4.4.5. I'm assuming it will try to reset my settings again as I see others are still facing this issue in the last few pages.
Is there any simple way to combat the settings reset or am I stuck setting everything back up from scratch? I assume my old qbit config will be overwritten each time I place it in the config folder and start the container since that's what happened last time. Is the only option to rebuild it via the UI following the upgrade?
-
TBH, I can't remember the complete context of this. What I do know:
1. My -arrs are now using the network of my VPN container so their traffic is routed through the same VPN tunnel.
2. I added this really odd feeling firewall rule and disabled "Drop Invalid":
Preface: I'm far from a network guru, hobbyist at best.
Looking back on it... The VPN containers probably use a internal private network. Whenever the application inside the docker container communicates to your LAN it's technically communicating from the network inside of the container and needs to be routed, thus hitting the firewall. The router has no idea about that network inside the container so it gets marked as invalid?
I'd still love to know the definitive answer if anyone has one.
-
I'm trying to move from OVPN to WireGuard and I'm running into a roadblock. Based on my logs I believe everything is starting properly, however, I cannot reach the webui. If I change 'wireguard' to 'openvpn' in the configuration I can reach the UI as expected. Any ideas?
docker run -d --name='binhex-delugevpn' --net='br0.10' --ip='192.168.10.15' --privileged=true -e TZ="America/New_York" -e HOST_OS="Unraid" -e 'TCP_PORT_8112'='8112' -e 'TCP_PORT_58846'='58846' -e 'TCP_PORT_58946'='58946' -e 'UDP_PORT_58946'='58946' -e 'TCP_PORT_8118'='8118' -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='xxxxxxxxxx' -e 'VPN_PASS'='xxxxxxxxxx' -e 'VPN_PROV'='pia' -e 'VPN_CLIENT'='wireguard' -e 'VPN_OPTIONS'='' -e 'STRICT_PORT_FORWARD'='yes' -e 'ENABLE_PRIVOXY'='no' -e 'LAN_NETWORK'='192.168.10.1/24' -e 'NAME_SERVERS'='209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1' -e 'DELUGE_DAEMON_LOG_LEVEL'='info' -e 'DELUGE_WEB_LOG_LEVEL'='info' -e 'ADDITIONAL_PORTS'='' -e 'DEBUG'='false' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -v '/mnt/disks/unassigned/downloads/':'/data':'rw' -v '/mnt/user/appdata/binhex-delugevpn':'/config':'rw' --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-delugevpn'
Created by... ___. .__ .__ \_ |__ |__| ____ | |__ ____ ___ ___ | __ \| |/ \| | \_/ __ \\ \/ / | \_\ \ | | \ Y \ ___/ > < |___ /__|___| /___| /\___ >__/\_ \ \/ \/ \/ \/ \/ https://hub.docker.com/u/binhex/ 2020-10-15 23:56:08.672244 [info] System information Linux 843aa7a70558 5.7.8-Unraid #1 SMP Thu Jul 9 11:10:03 PDT 2020 x86_64 GNU/Linux 2020-10-15 23:56:08.707765 [info] OS_ARCH defined as 'x86-64' 2020-10-15 23:56:08.755273 [info] PUID defined as '99' 2020-10-15 23:56:09.103466 [info] PGID defined as '100' 2020-10-15 23:56:09.722302 [info] UMASK defined as '000' 2020-10-15 23:56:09.741216 [info] Permissions already set for volume mappings 2020-10-15 23:56:09.841045 [info] Deleting files in /tmp (non recursive)... 2020-10-15 23:56:09.884032 [info] VPN_ENABLED defined as 'yes' 2020-10-15 23:56:09.906021 [info] VPN_CLIENT defined as 'wireguard' 2020-10-15 23:56:09.925092 [info] VPN_PROV defined as 'pia' 2020-10-15 23:56:14.841527 [info] WireGuard config file (conf extension) is located at /config/wireguard/wg0.conf 2020-10-15 23:56:14.875796 [info] VPN_REMOTE_SERVER defined as 'nl-amsterdam.privacy.network' 2020-10-15 23:56:14.934189 [info] VPN_REMOTE_PORT defined as '1337' 2020-10-15 23:56:14.953274 [info] VPN_DEVICE_TYPE defined as 'wg0' 2020-10-15 23:56:14.971720 [info] VPN_REMOTE_PROTOCOL defined as 'udp' 2020-10-15 23:56:14.995647 [info] LAN_NETWORK defined as '192.168.10.1/24' 2020-10-15 23:56:15.019885 [info] NAME_SERVERS defined as '209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1' 2020-10-15 23:56:15.039629 [info] VPN_USER defined as 'xxxxxxxx' 2020-10-15 23:56:15.063950 [info] VPN_PASS defined as 'xxxxxxxx' 2020-10-15 23:56:15.088321 [info] STRICT_PORT_FORWARD defined as 'yes' 2020-10-15 23:56:15.108386 [info] ENABLE_PRIVOXY defined as 'no' 2020-10-15 23:56:15.127681 [info] ADDITIONAL_PORTS not defined (via -e ADDITIONAL_PORTS), skipping allow for custom incoming ports 2020-10-15 23:56:15.153110 [info] DELUGE_DAEMON_LOG_LEVEL defined as 'info' 2020-10-15 23:56:15.174085 [info] DELUGE_WEB_LOG_LEVEL defined as 'info' 2020-10-15 23:56:15.199612 [info] Starting Supervisor... 2020-10-15 23:56:17,177 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing 2020-10-15 23:56:17,177 INFO Set uid to user 0 succeeded 2020-10-15 23:56:17,207 INFO supervisord started with pid 6 2020-10-15 23:56:18,209 INFO spawned: 'start-script' with pid 157 2020-10-15 23:56:18,210 INFO spawned: 'watchdog-script' with pid 158 2020-10-15 23:56:18,210 INFO reaped unknown pid 7 (exit status 0) 2020-10-15 23:56:18,226 DEBG 'start-script' stdout output: [info] VPN is enabled, beginning configuration of VPN 2020-10-15 23:56:18,227 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2020-10-15 23:56:18,227 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2020-10-15 23:56:18,229 DEBG 'start-script' stdout output: [info] Adding 209.222.18.222 to /etc/resolv.conf 2020-10-15 23:56:18,231 DEBG 'start-script' stdout output: [info] Adding 84.200.69.80 to /etc/resolv.conf 2020-10-15 23:56:18,234 DEBG 'start-script' stdout output: [info] Adding 37.235.1.174 to /etc/resolv.conf 2020-10-15 23:56:18,237 DEBG 'start-script' stdout output: [info] Adding 1.1.1.1 to /etc/resolv.conf 2020-10-15 23:56:18,239 DEBG 'start-script' stdout output: [info] Adding 209.222.18.218 to /etc/resolv.conf 2020-10-15 23:56:18,242 DEBG 'start-script' stdout output: [info] Adding 37.235.1.177 to /etc/resolv.conf 2020-10-15 23:56:18,245 DEBG 'start-script' stdout output: [info] Adding 84.200.70.40 to /etc/resolv.conf 2020-10-15 23:56:18,247 DEBG 'start-script' stdout output: [info] Adding 1.0.0.1 to /etc/resolv.conf 2020-10-15 23:56:19,487 DEBG 'start-script' stderr output: parse error: Invalid numeric literal at line 4, column 0 2020-10-15 23:56:20,125 DEBG 'start-script' stdout output: [info] Trying to connect to the PIA WireGuard API on 'nl-amsterdam.privacy.network'... 2020-10-15 23:56:20,642 DEBG 'start-script' stdout output: [info] Default route for container is 192.168.10.1 2020-10-15 23:56:20,654 DEBG 'start-script' stdout output: [info] Docker network defined as 192.168.10.0/24 2020-10-15 23:56:20,657 DEBG 'start-script' stdout output: [info] Adding 192.168.10.1/24 as route via docker eth0 2020-10-15 23:56:20,657 DEBG 'start-script' stderr output: Error: Invalid prefix for given prefix length. 2020-10-15 23:56:20,658 DEBG 'start-script' stdout output: [info] ip route defined as follows... -------------------- 2020-10-15 23:56:20,658 DEBG 'start-script' stdout output: default via 192.168.10.1 dev eth0 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.15 2020-10-15 23:56:20,658 DEBG 'start-script' stdout output: -------------------- 2020-10-15 23:56:20,661 DEBG 'start-script' stdout output: iptable_mangle 16384 2 ip_tables 28672 8 iptable_filter,iptable_raw,iptable_nat,iptable_mangle 2020-10-15 23:56:20,661 DEBG 'start-script' stdout output: [info] iptable_mangle support detected, adding fwmark for tables 2020-10-15 23:56:20,749 DEBG 'start-script' stdout output: [info] iptables defined as follows... -------------------- 2020-10-15 23:56:20,750 DEBG 'start-script' stdout output: -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP -A INPUT -s 192.168.10.0/24 -d 192.168.10.0/24 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --sport 1337 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 8112 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 8112 -j ACCEPT -A INPUT -s 192.168.10.0/24 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i wg0 -j ACCEPT -A OUTPUT -s 192.168.10.0/24 -d 192.168.10.0/24 -j ACCEPT -A OUTPUT -o eth0 -p udp -m udp --dport 1337 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 8112 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT -A OUTPUT -d 192.168.10.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -o wg0 -j ACCEPT 2020-10-15 23:56:20,751 DEBG 'start-script' stdout output: -------------------- 2020-10-15 23:56:20,753 DEBG 'start-script' stdout output: [info] Attempting to bring WireGuard interface 'up'... 2020-10-15 23:56:20,793 DEBG 'start-script' stderr output: Warning: `/config/wireguard/wg0.conf' is world accessible 2020-10-15 23:56:20,798 DEBG 'start-script' stderr output: [#] ip link add wg0 type wireguard 2020-10-15 23:56:20,799 DEBG 'start-script' stderr output: [#] wg setconf wg0 /dev/fd/63 2020-10-15 23:56:20,807 DEBG 'start-script' stderr output: [#] ip -4 address add 10.25.245.109/32 dev wg0 2020-10-15 23:56:20,812 DEBG 'start-script' stderr output: [#] ip link set mtu 1420 up dev wg0 2020-10-15 23:56:20,838 DEBG 'start-script' stderr output: [#] wg set wg0 fwmark 51820 2020-10-15 23:56:20,838 DEBG 'start-script' stderr output: [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 2020-10-15 23:56:20,839 DEBG 'start-script' stderr output: [#] ip -4 rule add not fwmark 51820 table 51820 2020-10-15 23:56:20,840 DEBG 'start-script' stderr output: [#] ip -4 rule add table main suppress_prefixlength 0 2020-10-15 23:56:20,842 DEBG 'start-script' stderr output: [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 2020-10-15 23:56:20,851 DEBG 'start-script' stderr output: [#] iptables-restore -n 2020-10-15 23:56:20,871 DEBG 'start-script' stderr output: [#] '/root/wireguardup.sh' 2020-10-15 23:56:22,128 DEBG 'start-script' stdout output: [info] Attempting to get external IP using Name Server 'ns1.google.com'... 2020-10-15 23:56:37,514 DEBG 'start-script' stdout output: [info] Successfully retrieved external IP address 212.102.34.182 2020-10-15 23:56:37,515 DEBG 'start-script' stdout output: [info] WireGuard interface 'up' 2020-10-15 23:56:37,515 DEBG 'start-script' stdout output: [info] Script started to assign incoming port 2020-10-15 23:56:37,516 DEBG 'start-script' stdout output: [info] Port forwarding is enabled [info] Checking endpoint 'nl-amsterdam.privacy.network' is port forward enabled... 2020-10-15 23:56:39,111 DEBG 'start-script' stdout output: [info] PIA endpoint 'nl-amsterdam.privacy.network' is in the list of endpoints that support port forwarding 2020-10-15 23:56:39,111 DEBG 'start-script' stdout output: [info] List of PIA endpoints that support port forwarding:- 2020-10-15 23:56:39,112 DEBG 'start-script' stdout output: [info] al.privacy.network [info] ad.privacy.network [info] austria.privacy.network [info] brussels.privacy.network [info] ba.privacy.network [info] sofia.privacy.network [info] czech.privacy.network [info] denmark.privacy.network [info] ee.privacy.network [info] fi.privacy.network [info] france.privacy.network [info] de-frankfurt.privacy.network [info] de-berlin.privacy.network [info] gr.privacy.network [info] hungary.privacy.network 2020-10-15 23:56:39,112 DEBG 'start-script' stdout output: [info] is.privacy.network [info] ireland.privacy.network [info] man.privacy.network [info] italy.privacy.network [info] lv.privacy.network [info] liechtenstein.privacy.network [info] lt.privacy.network [info] lu.privacy.network [info] mk.privacy.network [info] malta.privacy.network [info] md.privacy.network [info] monaco.privacy.network [info] montenegro.privacy.network [info] nl-amsterdam.privacy.network [info] no.privacy.network [info] poland.privacy.network [info] pt.privacy.network [info] ro.privacy.network [info] rs.privacy.network [info] sk.privacy.network [info] spain.privacy.network [info] sweden.privacy.network [info] swiss.privacy.network [info] ua.privacy.network [info] uk-manchester.privacy.network [info] uk-london.privacy.network [info] uk-southampton.privacy.network [info] bahamas.privacy.network [info] ca-vancouver.privacy.network [info] ca-ontario.privacy.network [info] ca-montreal.privacy.network [info] ca-toronto.privacy.network [info] greenland.privacy.network [info] mexico.privacy.network [info] panama.privacy.network [info] ar.privacy.network [info] br.privacy.network [info] venezuela.privacy.network [info] yerevan.privacy.network [info] cambodia.privacy.network [info] china.privacy.network [info] cyprus.privacy.network [info] georgia.privacy.network [info] hk.privacy.network [info] in.privacy.network [info] iran.privacy.network 2020-10-15 23:56:39,112 DEBG 'start-script' stdout output: [info] israel.privacy.network [info] japan.privacy.network [info] kazakhstan.privacy.network [info] philippines.privacy.network [info] qatar.privacy.network [info] saudiarabia.privacy.network [info] sg.privacy.network [info] srilanka.privacy.network [info] taiwan.privacy.network [info] tr.privacy.network [info] ae.privacy.network [info] vietnam.privacy.network [info] aus-perth.privacy.network [info] au-sydney.privacy.network [info] aus-melbourne.privacy.network [info] nz.privacy.network [info] dz.privacy.network [info] egypt.privacy.network [info] morocco.privacy.network [info] nigeria.privacy.network [info] za.privacy.network 2020-10-15 23:56:41,732 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '47146' 2020-10-15 23:56:42,196 DEBG 'watchdog-script' stdout output: [info] Deluge listening interface IP 0.0.0.0 and VPN provider IP 10.25.245.109 different, marking for reconfigure 2020-10-15 23:56:42,261 DEBG 'watchdog-script' stdout output: [info] Deluge not running 2020-10-15 23:56:42,263 DEBG 'watchdog-script' stdout output: [info] Deluge Web UI not running 2020-10-15 23:56:42,263 DEBG 'watchdog-script' stdout output: [info] Deluge incoming port 6890 and VPN incoming port 47146 different, marking for reconfigure 2020-10-15 23:56:42,270 DEBG 'watchdog-script' stdout output: [info] Attempting to start Deluge... [info] Removing deluge pid file (if it exists)... 2020-10-15 23:56:44,217 DEBG 'watchdog-script' stdout output: [info] Deluge key 'listen_interface' currently has a value of '10.26.129.208' [info] Deluge key 'listen_interface' will have a new value '10.25.245.109' [info] Writing changes to Deluge config file '/config/core.conf'... 2020-10-15 23:56:44,374 DEBG 'watchdog-script' stdout output: [info] Deluge key 'outgoing_interface' currently has a value of 'wg0' [info] Deluge key 'outgoing_interface' will have a new value 'wg0' [info] Writing changes to Deluge config file '/config/core.conf'... 2020-10-15 23:56:44,501 DEBG 'watchdog-script' stdout output: [info] Deluge key 'default_daemon' currently has a value of '9b89b378e26b43ed89a18c7b060d30de' [info] Deluge key 'default_daemon' will have a new value '9b89b378e26b43ed89a18c7b060d30de' [info] Writing changes to Deluge config file '/config/web.conf'... 2020-10-15 23:56:44,950 DEBG 'watchdog-script' stdout output: [info] Deluge process started [info] Waiting for Deluge process to start listening on port 58846... 2020-10-15 23:56:45,411 DEBG 'watchdog-script' stdout output: [info] Deluge process listening on port 58846 2020-10-15 23:56:47,515 DEBG 'watchdog-script' stdout output: Setting "random_port" to: False Configuration value successfully updated. 2020-10-15 23:56:49,315 DEBG 'watchdog-script' stdout output: Setting "listen_ports" to: (47146, 47146) Configuration value successfully updated. 2020-10-15 23:56:51,151 DEBG 'watchdog-script' stdout output: [info] No torrents with state 'Error' found 2020-10-15 23:56:51,152 DEBG 'watchdog-script' stdout output: [info] Starting Deluge Web UI... 2020-10-15 23:56:51,152 DEBG 'watchdog-script' stdout output: [info] Deluge Web UI started
-
I'm no pro, but have you tried to enable MSI in regedit?
-
I was trying to decide whether this was more of a Ubiquiti, Unraid or Docker question, but I figured you all would have a more well-rounded knowledge of the situation in it's entirety. So here goes:
The Issue
My sonarr (192.168.10.3) and radarr (192.168.10.4) dockers cannot communicate with my rtorrent (192.168.10.6) docker, but they can talk to sabnzbd (192.168.10.7). All stated dockers are assigned IP addresses via br0.10 with a gateway/mask of 192.168.10.1/24. I can see the traffic is being dropped by my firewall rules (see below), but my understanding is the packets should not hit the firewall because they're in the same VLAN/subnet (?).
Related Network Equipment
- Unifi Cloud Key
- Unifi USG
- Unifi 16 port Switch w/ 1GB LAG to Unraid Server
Problem Dockers
- linuxserver/sonarr:preview (br0.10, 192.168.10.3)
- linuxserver/radarr:latest (br0.10, 192.168.10.4)
- binhex-rtorrentvpn:latest (br0.10, 192.168.10.6)
I can connect to this one fine from sonarr/radarr on the other hand:
- binhex-sabnzbdvpn:latest (br0.10, 192.168.10.7)
Network
INTERFACE GATEWAY/MASK
br0.10 192.168.10.1/24
Relevant Firewall Rules (LAN IN)
RULE DESCRIPTION ACTION PROTOCOLS SOURCE DESTINATION
2000 Allow Established/Related Accept All Protocols
2001 Drop Invalid Drop All Protocols
(Pretty specific rules unrelated to dockers here. All are action=Allow)
2009 Disable Intervlan Routing Drop All Protocols Groups: RFC1918 Groups: RFC1918
According to Firewall Logging (why would these hit the firewall to begin with?)
- The packets from sonarr/radarr to rtorrent are dropped at rule 2001 when it is enabled.
- The packets are dropped at rule 2009 when 2001 is disabled.
- The connection is successful when both 2001 and 2009 are turned off.
Example Firewall Logs (I believe the connection is initiated from sonarr/radarr so I believe this is the response being dropped?)
-
With '2001 - Drop Invalid' enabled
[LAN_IN-2001-D]IN=eth1.10 OUT=eth1.10 MAC=78:8a:20:40:bd:e8:02:42:c0:a8:0a:06:08:00:45:00:00:3c SRC=192.168.10.6 DST=192.168.10.4 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=9443 DPT=51068 WINDOW=43440 RES=0x00 ACK SYN URGP=0 -
With '2009 - Disable Intervlan Routing' enabled (2001 disabled)
[LAN_IN-2009-D]IN=eth1.10 OUT=eth1.10 MAC=78:8a:20:40:bd:e8:02:42:c0:a8:0a:06:08:00:45:00:00:3c SRC=192.168.10.6 DST=192.168.10.4 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=9443 DPT=52090 WINDOW=43440 RES=0x00 ACK SYN URGP=0 - Not in logs, but connection is successful in sonarr/radarr when both rules are disabled.
Any thoughts, ideas are much appreciated!
-
16 hours ago, binhex said:
ok i was getting tripped up by my reverse proxy blocking access to /RPC2 externally, tried it internally and you are correct, i can indeed access /RPC2 with credentials. so had a look at the nginx config and this is the fix:-
open file /config/nginx/config/nginx.conf and look for the following section (there will be two occurrences):-
# include scgi for rtorent, specifying port 5000, important MUST use ip address location /RPC2 { include scgi_params; scgi_pass 127.0.0.1:5000; }so change this to be:-
# include scgi for rtorent, specifying port 5000, important MUST use ip address location /RPC2 { include scgi_params; scgi_pass 127.0.0.1:5000; auth_basic "Restricted Content"; auth_basic_user_file /config/nginx/security/auth; }once done save and restart the container, this for me then forces auth when connecting to /RPC2, give it a go if you have the same success as me then i will come up with some way of patching existing users config.
I can confirm this worked for me although I did end up doing a blanket auth on the proxy. Thanks again!
-
2
-
-
39 minutes ago, binhex said:
ok i was getting tripped up by my reverse proxy blocking access to /RPC2 externally, tried it internally and you are correct, i can indeed access /RPC2 with credentials. so had a look at the nginx config and this is the fix:-
open file /config/nginx/config/nginx.conf and look for the following section (there will be two occurrences):-
# include scgi for rtorent, specifying port 5000, important MUST use ip address location /RPC2 { include scgi_params; scgi_pass 127.0.0.1:5000; }so change this to be:-
# include scgi for rtorent, specifying port 5000, important MUST use ip address location /RPC2 { include scgi_params; scgi_pass 127.0.0.1:5000; auth_basic "Restricted Content"; auth_basic_user_file /config/nginx/security/auth; }once done save and restart the container, this for me then forces auth when connecting to /RPC2, give it a go if you have the same success as me then i will come up with some way of patching existing users config.
I'll give this a shot when I get home.
Just out of curiosity, in your setup, did you disable auth in the container and just use auth on the proxy? That seems like a good blanket fix.
You're the man binhex! Thanks for looking into it so quickly. Beer will definitely be coming your way.
-
For reference...
(And in NZB360, the upload/download speed update every 5 seconds so it's definitely making a full connection)
-
2 hours ago, binhex said:
i also use nzb360 and for me it will not allow me to connect to rutorrent via rpc2 without authentication details (as in ruTorrent username and password), do you have authentication enabled for the web ui?
Interesting. When I go to the :9443/ in a browser I get the default browser authentication popup and I log in with the username/password I created with the script inside the container. I can definitely verify that Sonarr/Radarr/NZB360 don't require authentication to the :9443/rpc2 endpoint currently.
Maybe I should delete my container/appdata and start from scratch?
-
4 hours ago, Cat_Seeder said:
You don't need to expose port 5000. Just expose 9443 (or 9080 if you are offloading Https to the proxy). As far as rutorrent is concerned it is talking to XML-RPC in the container's localhost.
If you are using other clients that require access to port 5000, you can use a similar strategy.
I've personally created a docker compose file for all applications that require access to rtorrent. Docker compose creates a shared network where services are discoverable by name (https://docs.docker.com/compose/networking/). Applications like Sonarr can access port 5000 even though it is not directly exposed to the internet. (E.g., use container hostname:5000)
I would not recommend exposing RPC2 over the internet. However, if you want to do it for whatever reason (e.g., Sonarr is running in a separate box in the internet and for whatever reason you don't want to use a VPN) you will need to really beef up security. Username and password is just a first measure; monitoring your logs, setting up fail2ban, etc are all good steps. Otherwise you will soon find a crypto miner installed at your server...
I admittedly don't have a deep understanding of rTorrent/ruTorrent but based on the little I know, port 5000 would be rTorrent (the backend) and 9080/9443 would be ruTorrent (the frontend, which is what I'd like to reverse proxy). This RPC2 endpoint seems to live on the front end (9080/9443).
Within my network, I've currently got NZB360 (an android app) pointed at https://192.168.1.4:9443/RPC2 (ports are all default) and it's working with no username or password.
-
I was considering using a reverse proxy to make rutorrent accessible from the web (mainly for NZB360), however, I was doing some research before I did so and it seems that RPC2 doesn't require auth (I think it used to?). To test, I removed my username/password from Sonarr, Radarr and NZB360, all three seem to connect without any username/password. Are others seeing this?
I don't think I've modified any configuration that would effect this. I've been using this container for a while but I think the deepest thing I've done configuration wise is add my own username/password and delete the default using the scripts.
-
3 hours ago, fatalfurry said:
I've seen a few headlines concerning rtorrent and it's security around xml-rpc
This was discussed on github in the following issue
https://github.com/rakshasa/rtorrent/issues/696
I don't see network.scgi.open_port or network.scgi.open_local set in the rtorrent.rc but in not 100% familiar with the setup of this docker container. Is there another place to check if this security issues affects us?
I saw this today as well.
I'm not very knowledgeable so take this with a grain of salt, but my understanding is you should be secure as long as you don't have the RPC port exposed ( I think it's port 5000 by default).
Again, I expect to be corrected... This is just my understanding.
-
13 minutes ago, IndianaJoe1216 said:
Is there a way to change the default username and password for the WebUI? Loving this container but I would like to be able to adjust that if possible.
This is copied from the description on DockerHub linked in the OP:
If you want to create an additional user account for ruTorrent webui then please execute the following on the host:-
docker exec -it <container name> /home/nobody/createuser.sh <username to create>If you want to delete a user account (or change the password for an account) then please execute the following on the host:-
docker exec -it <container name> /home/nobody/deluser.sh <username to delete> -
1 hour ago, GroxyPod said:
I'm trying to setup Sonarr with rTorrentVPN but I keep getting an issue where it says the connection failed.
I noticed that both httprpc and rpc are included within the docker, but I must be doing something wrong with regards to the URL path.
Here is what I have:
I tried searching through the support thread and came across someone having issues with sickbeard but even after attempting the suggested fix, I still can't get it to work.
Any help is appreciated, thank you!
Try URL Path in Sonarr as "RPC2" (no quotes).
-
I'm trying to automate the removal of torrents using ratio groups. FWIW, I also use Sonarr to pick the files up once they're downloaded.
I have one main ratio group that's set to Remove data (All). This seems to MOSTLY work, however, I also have unpack enabled and it won't delete the unpacked file which leads to an error in my Unraid log that says:
Feb 2 06:45:14 ZEUS shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/cache/downloads/complete/tv/xxxxxxxxxxxxxxxxxxxxxxxxx
Any ideas in Sonarr or RuTorrent? TIA!
-
On 11/29/2017 at 2:56 AM, david279 said:
I had my UNRAID server freeze up a bit while using this. Was watching a football game for about 2 hours and the transcoding must have filled the ram up till there was no memory left. I have 32 GB of RAM but I had a VM running at the same time. unRAID started killing off Dockers till it finally killed Plex. Works great for movies, TV shows etc but be careful with the DVR.
Sent from my SM-G955U using Tapatalk
I'm experiencing the same thing. I have 32GB of RAM total, using 16GB for my primary VM. It took me a while to figure out what was causing this because it had been working flawlessly for so long. Then I started realizing that it only happened when I was watching a channel on DVR for a long period of time. When it filled up the RAM it would lock the entire WebUI up (not that I would expect any less). I would then have to shut down the VM in order to have enough RAM to restart some of the services.
Thanks for confirming others are having the same issue. I've moved my transcode directory back to SSD for now.
[Support] binhex - qBittorrentVPN
in Docker Containers
Posted
Appreciate the response. Can you expand on what you did to manually restore? Did you just drop your old config back into appdata?