c0nfuzed

Yes, still getting an IPv6 address. The dig "-4" you added doesn't seem to make a difference... not sure why. I wasn't able to confirm the +1 issue, as I couldn't get the script to return an IPv4 address after an hour of testing. I was able to confirm that rTorrent is gettting the correct IP by doing a port test with NMAP (both my incoming port and DHT port were open, others closed). Perhaps, when the DNS method was returning an IPv4 address, it was wrong, not the web url. regardless, I think having alternative methods is a good thing. While the DNS method is considered best under most circumstances, it doesn't hurt to have fallback methods.

So after a bit of screwing around, I fixed my issue by creating a replacement getvpenextip.sh and mounting it into the container as follows. This new file uses the old DNS lookup method first, but if that fails it falls back to using curl to get the ip from http://checkip.amazonaws.com followed by http://whatismyip.akamai.com (both stable web presences). To test this: 1. create a file called getvpenextip.sh on the host OS containing: #!/bin/bash # define name servers to connect to in order to get external ip address pri_ns="ns1.google.com" sec_ns="resolver1.opendns.com" pri_url="http://checkip.amazonaws.com" sec_url="http://whatismyip.akamai.com" retry_count=30 # remove previous run output file rm -f /home/nobody/vpn_external_ip.txt # wait for vpn tunnel to come up before proceeding source /home/nobody/getvpnip.sh # function to check ip address is in correct format check_valid_ip() { check_ip="$1" # check if the format looks right echo "${check_ip}" | egrep -qE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' || return 1 # check that each octect is less than or equal to 255 echo "${check_ip}" | awk -F'.' '$1 <=255 && $2 <= 255 && $3 <=255 && $4 <= 255 {print "Y" } ' | grep -q Y || return 1 return 0 } while true; do if [[ "${DEBUG}" == "true" ]]; then echo "[debug] Attempting to get external IP using Name Server '${pri_ns}'..." fi external_ip="$(dig -b ${vpn_ip} -4 TXT +short o-o.myaddr.l.google.com @${pri_ns} 2> /dev/null | tr -d '"')" check_valid_ip "${external_ip}" return_code="$?" # if empty value returned, or ip not in correct format then try secondary ns if [[ -z "${external_ip}" || "${return_code}" != 0 ]]; then if [[ "${DEBUG}" == "true" ]]; then echo "[debug] Failed to get external IP using Name Server '${pri_ns}', trying '${sec_ns}'..." fi external_ip="$(dig -b ${vpn_ip} -4 +short myip.opendns.com @${sec_ns} 2> /dev/null)" check_valid_ip "${external_ip}" return_code="$?" fi # if empty value returned, or ip not in correct format then try first URL if [[ -z "${external_ip}" || "${return_code}" != 0 ]]; then if [[ "${DEBUG}" == "true" ]]; then echo "[debug] Failed to get external IP using Name Servers, trying '${pri_url}'..." fi external_ip="$(curl --interface ${vpn_ip} ${pri_url} 2> /dev/null)" check_valid_ip "${external_ip}" return_code="$?" fi # if empty value returned, or ip not in correct format then try secondary URL if [[ -z "${external_ip}" || "${return_code}" != 0 ]]; then if [[ "${DEBUG}" == "true" ]]; then echo "[debug] Failed to get external IP using Name Servers and primary URL, trying '${sec_url}'..." fi external_ip="$(curl --interface ${vpn_ip} ${sec_url} 2> /dev/null)" check_valid_ip "${external_ip}" return_code="$?" fi # if empty value returned, or ip not in correct format then retry if [[ -z "${external_ip}" || "${return_code}" != 0 ]]; then if [ "${retry_count}" -eq "0" ]; then external_ip="${vpn_ip}" echo "[warn] Cannot determine external IP address, exausted retries setting to tunnel IP ${external_ip}" break else retry_count=$((retry_count-1)) if [[ "${DEBUG}" == "true" ]]; then echo "[debug] Cannot determine external IP address, retrying..." fi sleep 1s continue fi fi echo "[info] Successfully retrieved external IP address ${external_ip}" break done # write external ip address to text file, this is then read by the downloader script echo "${external_ip}" > /home/nobody/vpn_external_ip.txt # chmod file to prevent restrictive umask causing read issues for user nobody (owner is user root) chmod +r /home/nobody/vpn_external_ip.txt 2. mount it over the container's version using the mount option: -v <host path>/getvpnextip.sh:/root/getvpnextip.sh:ro Hopefully BinHex will see this and consider updating his script. In the meantime this seems to be working for me.

Were you ever able to solve this issue? I'm also using Mullvad and I'm having the exact same issue... No.. BinHex never issued a fix. I'm sure I could edit the script, but I would much rather have it a "supported" solution. Sorry for the delayed response, I guess I am not getting email notifications.

If I had to guess, I would say its a permissions issue on the rtorrent side... check the logs, most likely its unable to save the torrent to the rtorrent/session directory or something.

Your .ovpn looks ok, but why not download the configuration files from https://www.ovpn.com/en/guides/debian (or elsewhere in the guides)? It's possible that yyou used an encryption cipher that is not being accelerated on the other end... though unlikely. Its possible that your ISP is causing trouble for you... you might try switching to TCP and port 443... while UDP is usually faster, running your VPN on TCP 443 disguises it as standard SSL web traffic and your ISP is far less likely to mess with your speeds. See: https://www.ovpn.com/en/faq/client/connect-using-tcp-443 in your config, change the following lines: remote VPNSERVERSOMETHING.ovpn.com 443 . . . proto tcp . . . You may also want to confirm that your system is reporting the correct IP to the trackers... I usually check this in rutorrent > settings > BitTorrent > IP/HostName to report to tracker. You will also find it by looking at the supervisord.log. If it's detecting the wrong external IP (as mine is) then external clients won't know where to go to download things. The last post by BinHex suggests that he is fixing something that may be related to this.

Very doubtful... if your storage is that slow, you have bigger issues. That doesn't make sense... why would you want a anonymous VPN if your going to have a dedicated IP address. The advantage of most VPN's is that there are many users behind one IP... so there is no obvious way to connect activity to an individual user unless the VPN provider is maintaining logs. I would need to know more about your VPN provider to figure out why your having slow speeds. As far as how the docker image is built, I don't believe there is any filtering being done... which is a bit scary if you have a dedicated IP and no filtering on inbound traffic (I would want an inbound firewall blocking everything but my listening ports).

Usually this means that you don't have a port mapped to allow incoming connections. You will still be able to seed, but it may take some time before you find leechers who can connect to you (since your node must make outgoing connections only). Your VPN host may allow port mapping... and if so, you need to set it up with them and set it in your rtorrent.rc file's port range like so (use the port number provided by your VPN host) # Port range to use for listening. port_range = 18586-18586 Alternatively... your system may not be detecting your external IP properly... and therefore it is reporting the wrong address to the tracker (which means that other systems cannot connect to you). I was discussing this with BinHex a page back since that is my issue. Finally... you just may not have anyone who wants your files... or they do, but because you have been having issues, they have blacklisted your IP for a while.

Don't look at it as 600 (six hundred). It's 6, 0, 0... or more accurately, 110 000 000 Linux permissions are set as 3 octal (3 bit) values... when you convert octal to decimal, the place values are 4,2,1... so 110 = 6. The first 3 bits (the 6) define read, write and execute for the user... the next three (0) define it for the group, and the next three (0) define it for everyone else. So the 6 (110 binary) means that the user has read and write, but no execute... the zeros for group and other mean that only the user has permissions. see: https://en.wikipedia.org/wiki/File_system_permissions#Numeric_notation or any article on linux file permissions... good thing to understand. But yes... 600 is correct here.

Just change the permissions on the file so that only the user has access: chmod 600 /mnt/cache/appdata/binhex-rtorrentvpn/openvpn/ovpn-tls.key

A warning is not an error. If you read the warning, it's simply saying that your .key file is readable by more than just the owner of the file. It warns of this because this may be a security concern on a shared system. I suspect this is not indicating the issue your experiencing. I would attach your full logs (redact your username password). That said.... you could just change the config directory in your run command, which would create a whole new set of files and just copy the ones over that you need from the old directory. That's what makes docker so great... nothing is permanent... you can just flush a container and start clean in a matter of seconds.

Not exactly sure what is wrong with that output you referenced... further down it says: ;; WARNING: The answer packet was truncated; you might want to ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size) Trying to use nslookup and dig via my host server does something similar (note the "Truncated, retrying in TCP mode."), not sure why dig in the docker container isn't retrying in TCP mode automatically?: /opt/appdata/rtorrent-openvpn/openvpn$ nslookup ca-on.mullvad.net 193.138.219.228 ;; Truncated, retrying in TCP mode. Server: 193.138.219.228 Address: 193.138.219.228#53 Non-authoritative answer: Name: ca-on.mullvad.net Address: 199.66.90.112 Name: ca-on.mullvad.net Address: 199.66.90.208 Name: ca-on.mullvad.net Address: 162.219.176.250 Name: ca-on.mullvad.net Address: 184.75.214.130 /opt/appdata/rtorrent-openvpn/openvpn$ dig ca-on.mullvad.net @193.138.219.228 ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.10.3-P4-Debian <<>> ca-on.mullvad.net @193.138.219.228 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7688 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 7 What are the "default" DNS servers? The one that I provided is the non-logging DNS server hosted by my VPN provider, and I would like to use it if possible. Besides, I think all of the issues I have found are fixable... and may save other folks some headaches. Follow up... from within in the container, I tested the Drill command and it works without fail. I assume that's because it is on the VPN and therefore the DNS queries are actually being redirected to their internal DNS servers per Mullvad's FAQ: I suspect the solution to this particular issue is simply to put a -t on /root/start.sh line 176 like so: echo "[debug] Show name resolution for VPN endpoint ${VPN_REMOTE}" ; drill -t "${VPN_REMOTE}" obviously, this just fixes the output in the debug log... doesn't change anything functionally.

Ok... got a successful and failed log file for you, and here is an example of why I suspect it's failing on the second one: [root@84f63622d18b /]# dig -b 10.9.0.3 TXT +short o-o.myaddr.l.google.com @ns1.google.com "2606:6080:1001:5::1d" On a subsequent boot I grabbed this... it just doesn't make sense how inconsistent it is (these are about 1 second apart): [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "2606:6080:1001:5::1d" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "2606:6080:1001:5::1d" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "2606:6080:1001:5::1d" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "2606:6080:1001:5::1d" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "2606:6080:1001:5::1d" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "2606:6080:1001:5::1d" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "2606:6080:1001:5::1d" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "2606:6080:1001:5::1d" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "184.75.214.130" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "184.75.214.130" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "184.75.214.130" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "184.75.214.130" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "184.75.214.130" [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "184.75.214.130" And notice, even when it does work... I'm not sure I'm getting the right address its always one bit smaller than what ipinfo.io reports: [root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com "184.75.214.130" [root@84f63622d18b /]# curl ipinfo.io/ip 184.75.214.131 The most obvious indication when it fails to get my public IP is that the address in "IP/Hostname to report to tracker" in ruTorrent is listed as my internal vpn IP (10.x.x.x) rather than an internet routable address. Needless to say, this will prevent seeding and may even violate some private tracker rules. supervisord.log supervisord.log.worked

I just found a bug, it only appears to have started recently so I suspect something changed at my VPN provider. The script that detects my public IP fails about 90% of the time because ... # from /root/getvpnextip.sh $(dig -b ${vpn_ip} TXT +short o-o.myaddr.l.google.com @${pri_ns} 2> /dev/null | tr -d '"') returns a IPv6 address rather than IPv4 as expected by the script. Additionally, and I'm not sure why, but when it does return an IPV4 address it is always different than what I get from curl ipinfo.io/ip by exactly 1... so if google's dns is reporting my IP is 1.1.1.1 then ipinfo.io/ip is reporting that it's 1.1.1.2... I don't fully understand why they would be different, but I fear that googles dns is wrong... might explain why I am not seeding as well as I would like.

I understand, and that is what I was addressing. Now if you have a dedicated routable IP address from your VPN provider, then you might have reason to be concerned. If your VPN provider was poorly implemented and allowed direct traffic between VPN customers, then you might have reason to be concerned. But those situations are exceedingly rare. Under normal circumstances, even if there is zero security baked into this image, and even if you made horrible configuration decisions... the fact that your behind NAT at the VPN provider will prevent anyone from leveraging this exploit. While NAT isn't as secure as a properly configured firewall, its damn effective at preventing exploits like this one. That said... here are the firewall rules inside the container on my system, 192.168.15.0/24 is my "LAN_NETWORK" in my startup command, it does appear to accept all incoming connections from the tun0 (VPN) interface... which is not ideal. (I may be reading this wrong, and I'm not sure how iptables and openVPN work together... perhaps the openvpn connection adds its own set of rules and this is normal). -P INPUT DROP -P FORWARD ACCEPT -P OUTPUT DROP -A INPUT -i tun0 -j ACCEPT -A INPUT -s 172.18.0.0/16 -d 172.18.0.0/16 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --sport 1195 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 9080 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 9080 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 9443 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 9443 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 3000 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --sport 3000 -j ACCEPT -A INPUT -s 192.168.15.0/24 -i eth0 -p tcp -m tcp --dport 5000 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -i lo -j ACCEPT -A OUTPUT -o tun0 -j ACCEPT -A OUTPUT -s 172.18.0.0/16 -d 172.18.0.0/16 -j ACCEPT -A OUTPUT -o eth0 -p udp -m udp --dport 1195 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 9080 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 9080 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 9443 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 9443 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 3000 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --sport 3000 -j ACCEPT -A OUTPUT -d 192.168.15.0/24 -o eth0 -p tcp -m tcp --sport 5000 -j ACCEPT -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A OUTPUT -o lo -j ACCEPT

A few things to consider before you start to worry. 1. This container is not exposed to the internet directly... it uses a VPN. When connected, it's public IP is not the IP of your machine, but the shared public IP of your VPN server.. often used by hundreds of others. (whole point of VPN for anonymity with torrenting) So an attacker cannot target your rtorrent server directly. 2. Because your running rtorrent behind a shared IP address, the ONLY way to allow an incoming connection is with a port forward, and in most cases, the only port you would forward would be the rtorrent "listening port", if any, and only if your VPN provider even allows it. 3. When you start the container, you specify ports mappings... there is little reason to create a port mapping for the RPC port 5000 unless you are planning on running rutorrent or other XML-RPC management tools outside the container. Because rutorrent is included inside, this is very unlikely. That said, even if network.scgi.open_port is set, you are safe using this unless you made some very intentional implementation decisions to expose RPC to the world ( for example added a port mapping for port 5000 in docker and at your VPN provider).