Docker-transmission-openvpn: Transmission RPC authentication error

[sylarevan]

Hi there,

I just noticed a few days ago that my container was not able to connect to PIA anymore with the 1.15 image :

PIA returned an error: "error":"Unauthorized, please check username and password"

Digging a little shows that I should now use the dev version, which I did, with no success so far. The first issue was the following:

STARTING TRANSMISSION stdout
12:18:03 CONFIGURING PORT FORWARDING
12:18:03 Transmission startup script complete.
12:18:03 Sat Apr 29 12:18:03 2017 Initialization Sequence Completed
12:18:03 Generating new client id for PIA
12:18:04 Got new port 38342 from PIA
12:18:04 transmission auth required
12:18:04 Unexpected response:

401: Unauthorized

Unauthorized UserwMGMxd1U0SktjSA==
12:18:04 User-Agent: transmission-remote/2.92 (14714)
12:18:04 Host: localhost:9091
12:18:04 Accept: /
12:18:04 Accept-Encoding: deflate, gzip

This seems related to authentication failure with Transmission itself, not to PIA, while I haven't changed anything in the way I launch the container.

Playing again with some options, I now get:

STARTING TRANSMISSION
CONFIGURING PORT FORWARDING
Transmission startup script complete.
Sat Apr 29 12:50:00 2017 Initialization Sequence Completed
Generating new client id for PIA
Port forwarding is already activated on this connection, has expired, or you are not connected to a > PIA region that supports port forwarding
curl encountered an error looking up new port: 56

So, for now, I'm not able to use the dev or 1.15 version anymore.

FYI, I'm using the following to launch the container (on a Synology NAS):

docker run -d --restart=always --cap-add=NET_ADMIN --device=/dev/net/tun -v /volume1/docker/transmission/resolv.conf:/etc/resolv.conf -v /volume1/transmission:/data -e "OPENVPN_PROVIDER=PIA" -e "OPENVPN_CONFIG=Netherlands" -e "OPENVPN_USERNAME=XXXXX" -e "OPENVPN_PASSWORD=XXXXX" -e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60" -e "TRANSMISSION_RPC_WHITELIST_ENABLED=false" -e "TRANSMISSION_RPC_USERNAME=XXXXX" -e "TRANSMISSION_RPC_PASSWORD=XXXXXX" -e "TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true" -e "TRANSMISSION_INCOMPLETE_DIR_ENABLED=true" -e "TRANSMISSION_INCOMPLETE_DIR=/data/_Incomplete" -e "TRANSMISSION_DOWNLOAD_DIR=/data/_Completed" -e "TRANSMISSION_WATCH_DIR=/data/_Watch" -e "TRANSMISSION_BLOCKLIST_ENABLED=true" -e "TRANSMISSION_BLOCKLIST_URL=http://ip2k.com/list.gz" -e "TRANSMISSION_DOWNLOAD_QUEUE_SIZE=10" -e "TERM=xterm" -p 9091:9091 --name transmission haugene/transmission-openvpn:dev

EDIT: just tried with another country (Sweden this time), and I now get the Unauthorized transmission error.

[sylarevan]

Some news:
So far, I was using for TRANSMISSION_RPC_PASSWORD the password hash, automagically generated, well ... a long time ago I guess. Using it, I am able with the dev version to use Transmission remote client and the web GUI, but the container shows the 401: Unauthorized error mentioned above.

If I now use the "real" password (not the hash), the container can then correctly connect to both PIA and transmission, but I am not able to connect to Transmission anymore from my client or web GUI.

So I do not understand whats happening so far: something strange is happening with transmission authentication...

Any ideas?

[avluis]

Just to throw a few troubleshooting ideas at you -- since you are using a Synology (I have a DS2415+ to play with here);
Have you double checked that the tunnel is active on the Synology (or for simplicity, do you have the VPN package installed)?
Do you mind exporting and posting the container json file from Docker GUI?
Make sure to remove all sensitive data!!

[sylarevan]

Have you double checked that the tunnel is active on the Synology (or for simplicity, do you have the VPN package installed)?

Yep, the package is up and running. Additionnally, I have a startup script which loads the tun module if needed:

# Create the necessary file structure for /dev/net/tun
if ( [ ! -c /dev/net/tun ] ); then
    if ( [ ! -d /dev/net ] ); then
        mkdir -m 755 /dev/net
    fi
    mknod /dev/net/tun c 10 200
fi

# Load the tun module if not already loaded
if ( !(lsmod | grep -q "^tun\s") ); then
    insmod /lib/modules/tun.ko
fi

From the container, I've also checked which IP i get, showing that the VPN is correctly running.

The json file from the container can be downloaded here

[avluis]

Only a few things stood out at me - one of which is that you are linking the tunnel file (I didn't have to do this) but this shouldn't cause your issue -- and the other is that you are missing your LOCAL_NETWORK variable -- go ahead and set that to your subnet; eg; 192.168.2.0/24 for 192.168.2.1-254 (255.255.255.0 netmask).
This is the relevant area in the readme addressing the above: https://github.com/haugene/docker-transmission-openvpn#network-configuration-options

[sylarevan]

I've just added the LOCAL_NETWORKvariable to 192.168.1.0/24, which is my local network subnet. No changes so far, the container starts correctly et openvpn is working, while I'm not able to connect to transmission from the web GUI (401 error code). In the container, everything seems OK:

10:53:45 STARTING TRANSMISSION
10:53:45 CONFIGURING PORT FORWARDING
10:53:45 Transmission startup script complete.
10:53:45 Wed May  3 10:53:45 2017 Initialization Sequence Completed
10:53:45 Generating new client id for PIA
10:53:46 Got new port 38644 from PIA
10:53:46 transmission auth required
10:53:47 localhost:9091/transmission/rpc/ responded: "success"
10:53:47 Checking port...
10:53:57 Port is open: Yes

[avluis]

401 is invalid credentials -- are there any special characters in any of those variables:

`\":/*<>?

Next thing to try is to use a DockerEnv file instead of defining your variables at runtime.

[sylarevan]

401 is invalid credentials -- are there any special characters in any of those variables:

Yes, that's it! I use a password manager to generate my passwords, and it was indeed using a ^. This was not a problem before, so something must have changed since v1.15 (but remember that I was using the password hash before, which seems not possible anymore now).

Anyway, using a new password with (a lot of!) letters/numbers only works well now.

Thank you!

[avluis]

Neat~ Don't forget to close this issue if it has been resolved~

[gulo-gulo]

@avluis @sylarevan this just helped me out BIG TIME. thanks a ton y'all