search

haugene / docker-transmission-openvpn

Docker container running Transmission torrent client with WebUI over an OpenVPN tunnel
GNU General Public License v3.0
4.1k stars 1.2k forks source link

Unable to Access WebUI, logs only show success #2762

Closed DaGeek247 closed 9 months ago

DaGeek247 commented 9 months ago

Is there a pinned issue for this?

Is there an existing or similar issue/discussion for this?

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Docker run config used

docker run --cap-add=NET_ADMIN -d \ -v /mnt/tnas/transqbt:/config \ -v /mnt/quintssd/torrcache2/:/cache \ -v /mnt/tnas/:/data \ -e OPENVPN_PROVIDER=PROTONVPN \ -e OPENVPN_CONFIG=us.protonvpn.net.udp \ -e OPENVPN_USERNAME=name \ -e OPENVPN_PASSWORD=pass \ -e LOCAL_NETWORK=192.168.2.0/24 \ -e HEALTH_CHECK_HOST=github.com \ --log-driver json-file \ --log-opt max-size=10m \ -p 9091:9091 \ --name transqbt \ haugene/transmission-openvpn

Current Behavior

As far as I can see, the logs say that everything is running fine. However, when I try to load the webui, i get the following reply from the url in my browser; NS_ERROR_CONNECTION_REFUSED

Expected Behavior

I expect the webui to display.

How have you tried to solve the problem?

the local network is on 192.168.2.1-255, with the container located on 192.168.2.185.

I have tried adding the following adjustment to my run command with various IP/websites; -e HEALTH_CHECK_HOST=github.com \

I have also followed the debug setup guide with the following results;

root@9d2e7db1e582:/# curl localhost:9091 curl: (7) Failed to connect to localhost port 9091: Connection refused

I have also tried adjusting the ports allowed through to ones that worked with other containers, which also did not work.

Log output

Starting container with revision: 94754fe91d3a430bafa6b0dec75f56ded43ef1df Creating TUN device /dev/net/tun Using OpenVPN provider: PROTONVPN Running with VPN_CONFIG_SOURCE auto No bundled config script found for PROTONVPN. Defaulting to external config Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.AvdLLsGTDi Extracting configs to /tmp/tmp.eAHzAYQd9B Found configs for PROTONVPN in /tmp/tmp.eAHzAYQd9B/vpn-configs-contrib-main/openvpn/protonvpn, will replace current content in /etc/openvpn/protonvpn Cleanup: deleting /tmp/tmp.AvdLLsGTDi and /tmp/tmp.eAHzAYQd9B Starting OpenVPN using config us.protonvpn.net.udp.ovpn Modifying /etc/openvpn/protonvpn/us.protonvpn.net.udp.ovpn for best behaviour in this container Modification: Point auth-user-pass option to the username/password file Modification: Change ca certificate path Modification: Change ping options Modification: Update/set resolv-retry to 15 seconds Modification: Change tls-crypt keyfile path Modification: Set output verbosity to 3 Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop Setting OpenVPN credentials... adding route to local network 192.168.2.0/24 via 172.17.0.1 dev eth0 Wed Dec 13 02:12:36 2023 Multiple --up scripts defined. The previously configured script is overridden. Wed Dec 13 02:12:36 2023 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022 Wed Dec 13 02:12:36 2023 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 Wed Dec 13 02:12:36 2023 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Wed Dec 13 02:12:36 2023 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Wed Dec 13 02:12:36 2023 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Wed Dec 13 02:12:36 2023 TCP/UDP: Preserving recently used remote address: [AF_INET]89.45.4.2:5060 Wed Dec 13 02:12:36 2023 Socket Buffers: R=[212992->212992] S=[212992->212992] Wed Dec 13 02:12:36 2023 UDP link local: (not bound) Wed Dec 13 02:12:36 2023 UDP link remote: [AF_INET]89.45.4.2:5060 Wed Dec 13 02:12:36 2023 TLS: Initial packet from [AF_INET]89.45.4.2:5060, sid=0126005b 5b41d4cf Wed Dec 13 02:12:36 2023 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Wed Dec 13 02:12:37 2023 VERIFY OK: depth=2, C=CH, O=ProtonVPN AG, CN=ProtonVPN Root CA Wed Dec 13 02:12:37 2023 VERIFY OK: depth=1, C=CH, O=ProtonVPN AG, CN=ProtonVPN Intermediate CA 1 Wed Dec 13 02:12:37 2023 VERIFY KU OK Wed Dec 13 02:12:37 2023 Validating certificate extended key usage Wed Dec 13 02:12:37 2023 ++ Certificate has EKU (str) 1.3.6.1.5.5.8.2.2, expects TLS Web Server Authentication Wed Dec 13 02:12:37 2023 ++ Certificate has EKU (oid) 1.3.6.1.5.5.8.2.2, expects TLS Web Server Authentication Wed Dec 13 02:12:37 2023 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Server Authentication Wed Dec 13 02:12:37 2023 ++ Certificate has EKU (oid) 1.3.6.1.5.5.7.3.2, expects TLS Web Server Authentication Wed Dec 13 02:12:37 2023 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Wed Dec 13 02:12:37 2023 VERIFY EKU OK Wed Dec 13 02:12:37 2023 VERIFY OK: depth=0, CN=node-us-164.protonvpn.net Wed Dec 13 02:12:37 2023 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1634' Wed Dec 13 02:12:37 2023 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500' Wed Dec 13 02:12:37 2023 WARNING: 'cipher' is present in local config but missing in remote config, local='cipher AES-256-CBC' Wed Dec 13 02:12:37 2023 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo' Wed Dec 13 02:12:37 2023 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA Wed Dec 13 02:12:37 2023 [node-us-164.protonvpn.net] Peer Connection Initiated with [AF_INET]89.45.4.2:5060 Wed Dec 13 02:12:38 2023 SENT CONTROL [node-us-164.protonvpn.net]: 'PUSH_REQUEST' (status=1) Wed Dec 13 02:12:38 2023 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.24.0.1,sndbuf 524288,rcvbuf 524288,redirect-gateway def1,explicit-exit-notify,comp-lzo no,route-gateway 10.24.0.1,topology subnet,ping 10,ping-restart 60,socket-flags TCP_NODELAY,ifconfig 10.24.0.6 255.255.0.0,peer-id 524292,cipher AES-256-GCM' Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: timers and/or timeouts modified Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: explicit notify parm(s) modified Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: compression parms modified Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified Wed Dec 13 02:12:38 2023 Socket Buffers: R=[212992->1048576] S=[212992->1048576] Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: --socket-flags option modified Wed Dec 13 02:12:38 2023 NOTE: setsockopt TCP_NODELAY=1 failed Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: --ifconfig/up options modified Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: route options modified Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: route-related options modified Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: peer-id set Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: adjusting link_mtu to 1656 Wed Dec 13 02:12:38 2023 OPTIONS IMPORT: data channel crypto options modified Wed Dec 13 02:12:38 2023 Data Channel: using negotiated cipher 'AES-256-GCM' Wed Dec 13 02:12:38 2023 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Wed Dec 13 02:12:38 2023 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Wed Dec 13 02:12:38 2023 ROUTE_GATEWAY 172.17.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:00:02 Wed Dec 13 02:12:38 2023 TUN/TAP device tun0 opened Wed Dec 13 02:12:38 2023 TUN/TAP TX queue length set to 100 Wed Dec 13 02:12:38 2023 /sbin/ip link set dev tun0 up mtu 1500 Wed Dec 13 02:12:38 2023 /sbin/ip addr add dev tun0 10.24.0.6/16 broadcast 10.24.255.255 Wed Dec 13 02:12:38 2023 /etc/openvpn/update-resolv-conf tun0 1500 1584 10.24.0.6 255.255.0.0 init Wed Dec 13 02:12:38 2023 /sbin/ip route add 89.45.4.2/32 via 172.17.0.1 Wed Dec 13 02:12:38 2023 /sbin/ip route add 0.0.0.0/1 via 10.24.0.1 Wed Dec 13 02:12:38 2023 /sbin/ip route add 128.0.0.0/1 via 10.24.0.1 Wed Dec 13 02:12:38 2023 Initialization Sequence Completed

HW/SW Environment

- OS: Debian GNU/Linux 11 (bullseye)
- Docker:
Client: Docker Engine - Community
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        afdd53b
 Built:             Thu Oct 26 09:08:20 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       311b9ff
  Built:            Thu Oct 26 09:08:20 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.26
  GitCommit:        3dd1e886e55dd695541fdcd67420c2888645a495
 runc:
  Version:          1.1.10
  GitCommit:        v1.1.10-0-g18a0cb0
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Anything else?

My best guess is that despite being open, the ports are somehow still not allowed through. I have no idea where to go from here to resolve the issue though. The docker ps -a command shows the container as degraded but running: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9d2e7db1e582 haugene/transmission-openvpn "dumb-init /etc/open…" 27 minutes ago Up 27 minutes (unhealthy) 8118/tcp, 0.0.0.0:9091->9091/tcp, :::9091->9091/tcp transqbt

edgd1er commented 9 months ago

That line Wed Dec 13 02:12:36 2023 Multiple --up scripts defined. The previously configured script is overridden.seems to show a incorrect setting, but I could not point out the cause of the error. starting with DEBUG=true may show some interesting information.

My guess is that transmission is not running. in the container , could you check with ps -fp $(pgrep transmission) ? expected result is something like:

root@217301721ddf:/app# ps -fp $(pgrep transmission)
UID          PID    PPID  C STIME TTY          TIME CMD
abc         1167    1166  0 Dec10 ?        00:06:31 /usr/local/bin/transmission-daemon -f -g /config/transmission-home --logfile /config/transmission-home/transmission.log

if transmission crashed, transmission.log may give you some information about the problem.

DaGeek247 commented 9 months ago

Transmission does not appear to be running, and after trying to run the command on a different desktop, I have noticed that the config directory does not have any folders created in it when the container is ran for the first time. It does have the credentials.txt files created though, so it's not a permission issue?

in short - the transmission log file does not exist, but the transmission and vpn credential files do exist.

Debug enabled log: https://github.com/haugene/docker-transmission-openvpn/files/13656849/debug.enabled.log.txt

edgd1er commented 9 months ago

@DaGeek247 please redact you debug log or remove the file, your credentials are displayed.

having no log in /config/transmission-home/ would suggest that transmission crash just after starting.

With the debug activate, you have the comand line: openvpn --script-security 2 --up-delay --up /etc/openvpn/tunnelUp.sh --route-pre-down /etc/openvpn/tunnelDown.sh --config /etc/openvpn/protonvpn/us.protonvpn.net.udp.ovpn

if you run that line in the container, you may have more information in the console.

ilike2burnthing commented 9 months ago

@DaGeek247 you'll need to delete your edit history as well. At this point, it's probably safer to assume your account is compromised and reset your credentials.

DaGeek247 commented 9 months ago

yeah, it's been reset. i've put the log file back for legibility. The results of the above command are attached.

special command log.txt

edgd1er commented 9 months ago

the command failed because routes were already added. so executing again the openvpn command does not provide a solution. Could you try a curl http://ifconfig.me/ipto check that the ip displayed is not your internet provider'ip.

it seems that the tunnelUp.sh script is ignored:

Wed Dec 13 06:00:56 2023 Multiple --up scripts defined.  The previously configured script is overridden.

Could the file us.protonvpn.net.udp.ovpncontain a script instruction ? (it seems that protonvpn needs a pre up/post down script to define dns: https://raw.githubusercontent.com/ProtonVPN/scripts/master/update-resolv-conf.sh) i suspect that this script is overriding the tunnelUp.sh

Thu Dec 14 02:40:04 2023 /etc/openvpn/update-resolv-conf tun1 1500 1584 10.21.0.6 255.255.0.0 init

the fix will be to find how to change scripts order to have tunnelUp.sh executing update-resolv.conf.

As a workaround, Assuming openvpn is up and running ( ie ifconfig.me dit not return your public ip but the vpn's ip), you may try to launch transmission directly. The problem is openvpn runs the tunnelUp script with arguments:

"${dev}" "${tun_mtu}" "${link_mtu}" "${ifconfig_local}" "${ifconfig_remote}" "${script_context}"

the start script does not use all arguments, so we can simplify the arg lists According to your last log, it could be something like.

/etc/transmission/start.sh tun1 notused notused 10.21.0.6 notused notused

please adapt local ifconfig (10.21.0.6) according to the log. find this type of line in the log, the 4th args is the local ip.

Thu Dec 14 02:40:04 2023 /etc/openvpn/update-resolv-conf tun1 1500 1584 10.21.0.6 255.255.0.0 init

to sum up, it seems to be a proton's specific problem.

DaGeek247 commented 9 months ago

running curl from the container loads the vpn ip as expected. Running your command started transmission and allowed me to connect to the website/add new torrents. However, transmission is unable to connect to any of the trackers i've tried. (ipleak.net and also the latest debian torrent)

relevant logs: ran transmission log.txt transmission web results.txt

checking the ip of the container after transmission is started leaks my current ip, not the vpn ip. pinging google works fine though.

edgd1er commented 9 months ago

there are three issues to address here:

To avoid ip leakage there is an ENV var named DROP_DEFAULT_ROUTE to set to true

DaGeek247 commented 9 months ago

I am embarrassed to say that I have been trying to run a docker container version which had a 2.xx transmission client in it, because i tested it ages ago, and when i started a new attempt this past week, docker didn't bother to check if there were any updates available. updating my docker image fixed the crashing problem.

I switched to a "router" version of the ovpn files from proton vpn, and that fixed the script conflicts i had been having. i really wish i'd known that docker doesn't bother to update images unless you explicitly tell it to, and more importantly, just what sort of wild problems that can end up causing.

Thank you so much for walking me through this problem.