ban bait? binhex/arch-rtorrentvpn overrides settings with forced ip spoof

[gabbyendo]

When I set this up as a new docker container, it consistently avoids my rtorrent configured local ip and overrides it by running rtorrent with "-o ip=216.239.32.10" (you can see it was spawned like this via htop, e.g.) spoofing the IP even though I don't want it to (and breaking the port open detect in the process). I use wireguard with a custom vpn, and everything works except I can't figure out how to stop this docker container from consistently trying to override my defined local ip with this spoofed google ip. I can't find this IP in the source files here. Is it coming from a package you're pulling? Is it being generated somehow?

How do I get your docker container to stop trying to spawn rtorrent with an ip spoof? Searching the entire /config directory shows that it keeps getting written directly into my rutorrent .dat file (read from the -o flag?)

This is behavior that can get you banned in some communities, but is being forcibly enabled repeatedly by container creation with binhex/arch-rtorrentvpn and breaking user expectation by overriding manually set config

[binhex]

it consistently avoids my rtorrent configured local ip and overrides it by running rtorrent with "-o ip=216.239.32.10" (you can see it was spawned like this via htop, e.g.) spoofing the IP even though I don't want it to (and breaking the port open detect in the process).

its not 'spoofing' anything, that ip address is the external ip address that is allocated to you from your vpn provider, if you dont want it to do this then switch off the vpn by setting VPN_ENABLED to 'no', then you are free to set it to whatever you want.

[gabbyendo]

that ip address is the external ip address that is allocated to you from your vpn provider

This is not the case. That IP is a Google nameserver IP (ns1.google.com) and is certainly not my external VPN IP (nor could a nameserver be anyone's external VPN IP). A VPN is correctly, intentionally, being used. The IP I'm talking about is the one under "IP/Hostname to report to the tracker" in rutorrent settings. If it's different from your VPN external IP, you get two IPs listed when e.g. using an internet torrent IP checker, and people say you're 'spoofing' your IP. If you want this to just be your VPN IP, you can set it to 0.0.0.0 (or your actual VPN external IP), but mine is getting consistently set to 216.239.32.10 (a Google nameserver IP) by the docker container.

If the intention is to in fact set this IP to your VPN IP, it could be that something is broken in the detection? Where is the code that tries to detect this? Although this is altogether unneeded since it could just be set to 0.0.0.0 (or not at all so it stops overriding your rtorrent config).

Is there no way to disable the config override without disabling the VPN?

[gabbyendo]

❯ grep -rnw './arch-rtorrentvpn/' -e 'external_ip'
./arch-rtorrentvpn/run/nobody/rtorrent.sh:33:           rtxmlrpc network.local_address.set '' "${external_ip}"
./arch-rtorrentvpn/run/nobody/rtorrent.sh:53:                   /usr/bin/script /home/nobody/typescript --command "/usr/bin/tmux new-session -d -s rt -n rtorrent /usr/bin/rtorrent -b ${vpn_ip} -p ${VPN_INCOMING_PORT}-${VPN_INCOMING_PORT} -o ip=${external_ip} -o dht_port=${VPN_INCOMING_PORT}"
./arch-rtorrentvpn/run/nobody/rtorrent.sh:61:                   /usr/bin/script /home/nobody/typescript --command "/usr/bin/tmux new-session -d -s rt -n rtorrent /usr/bin/rtorrent -b ${vpn_ip} -o ip=${external_ip}"

It's still not clear where $external_ip is getting set and why it could be getting set incorrectly. Is it possible that code fails with wireguard specifically? Are you sure this is necessary to set for some users? Have you considered setting local_address to 0.0.0.0 (or not at all)? This would avoid whatever code is (apparently) detecting external_ip incorrectly.

Independently of the above issue, it might make sense to check here if network.local_address.set is already set in a user's rtorrent.rc (and reading it off or avoiding the setting then) to avoid overriding it.

[gabbyendo]

You can resolve the IP of ns1.google.com to confirm that cannot be my external VPN IP:

❯ nslookup ns1.google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   ns1.google.com
Address: 216.239.32.10
Name:   ns1.google.com
Address: 2001:4860:4802:32::a

[gabbyendo]

Here's the relevant log bit in the container:

[info] Attempting to get external IP using Name Server 'ns1.google.com'...
[info] Successfully retrieved external IP address 216.239.32.10

For some reason it is failing by returning the IP of ns1.google.com instead of the real external IP. It appears you hardcoded ns1.google.com in the upstream container which solves the mystery of where the IP is coming from, but not why it's failing in the first place.

[binhex]

Ok I will take a further look, but it won't be for at least a week as I'm off on vacation.

[gabbyendo]

For reproduction sake, I'm testing with mullvad wireguard and the following appropriately modified config:

sudo docker run -d \
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
  --privileged=true \
  -p 9080:9080 \
  -p 9443:9443 \
  --name=rtorrent \
  -v /mnt/data/dir/:/data \
  -v /mnt/config/dir/:/config \
  -v /etc/localtime:/etc/localtime:ro \
  -e VPN_ENABLED=yes \
  -e VPN_PROV=custom \
  -e VPN_CLIENT=wireguard \
  -e ENABLE_PRIVOXY=no \
  -e ENABLE_AUTODL_IRSSI=no \
  -e ENABLE_RPC2=no \
  -e ENABLE_RPC2_AUTH=no \
  -e ENABLE_WEBUI_AUTH=yes \
  -e RPC2_USER=admin \
  -e RPC2_PASS=passwordhere \
  -e WEBUI_USER=admin \
  -e WEBUI_PASS=passwordhere \
  -e LAN_NETWORK="$lan_ip" \
  -e NAME_SERVERS=1.1.1.1,1.0.0.1 \
  -e ADDITIONAL_PORTS=mullvad-portforwarded-port-here \
  -e DEBUG=false \
  -e PHP_TZ=my/timezone \
  -e UMASK=022 \
  -e PUID=1000 \
  -e PGID=1000 \
  binhex/arch-rtorrentvpn

[gabbyendo]

The only other thing I can think of that could be of note is my connection is IPv6 capable, however the problem does still occur if I run the docker container with --dns-opt='options single-request' --sysctl "net.ipv6.conf.all.disable_ipv6=1".

After the problem is identified and fixed it might be worth placing a note on the affected torrent container READMEs for a little while so banned users can point to it as proof it was unintentional.

[binhex]

ok i will take a look at this tonight, fyi i believe the issue is specific to your vpn provider, which i noted is mullvad, the lookup of the external ip works well, but for some reason mullvad doesnt play nicely with the name server lookup, so i might have to do something special for mullvad, which is a bit crap, but hey there ya go.

[binhex]

oh and btw you misunderstand the use of additional_ports, this is can be used when routing multiple containers through this one, and allows you to define additional web ui ports required, it is not to be used to specify the incoming port, from your run command:-

-e ADDITIONAL_PORTS=mullvad-portforwarded-port-here

[binhex]

ok so i have ripped out the external ip address detection using name servers, so it uses website lookup instead, i should have a new image for you to test shortly which should fix this up for you.

[binhex]

ok new image done, please pull down and let me know if it fixes the issue.

[gabbyendo]

ok new image done, please pull down and let me know if it fixes the issue.

I pulled the update and it's working fine to now correctly pass the external VPN IP as the -o parameter when launching and such. Thanks for looking into it and fixing it!