haugene / docker-transmission-openvpn

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

Docker crashes 30-60 seconds after starting #2558

Closed recontwo closed 1 year ago

recontwo commented 1 year 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

Not sure what the actual issue is, if i'm just configuring it wrong, or missing something, so if this is in the wrong area I do apologize. Just started trying to use dockers a few days ago so its all pretty new.

docker run -d \
  --name transmission-openvpn \
  --cap-add=NET_ADMIN \
  -e OPENVPN_PROVIDER=custom \
  -e OPENVPN_CONFIG=default \
  -e OPENVPN_USERNAME=xxxxxxxxx \
  -e OPENVPN_PASSWORD=yyyyyyyyy \
  -e WEBPROXY_ENABLED=false \
  -e CREATE_TUN_DEVICE=true \
  -p 9091:9091 \
  -e LOCAL_NETWORK=192.168.1.0/24 \
  -e PUID=1026 \
  -e PGID=100 \
  --dns 8.8.8.8 \
  -e TZ=America/Phoenix \
  -e OPENVPN_OPTS="--route-delay 2 --verb 3" \
  -v /volume1/docker/config/openvpn:/config \
  -v /volume1/docker/config/openvpn:/etc/openvpn/custom \
  -v /volume1/docker/transmission:/downloads \
  --log-driver json-file \
  --log-opt max-size=10m \
  --network=vpn_net \
  haugene/transmission-openvpn

the vpn files cyberghost gave me when I created the connection to test it are uploaded to /volume1/docker/config/openvpn

default.ovpn file (fixed one issue where i was getting --file not found for the ca, client crt and key by adding /etc/openvpn/custom to the path)

client
remote 87-1-us.cg-dialup.net 443
dev tun
proto udp
auth-user-pass /config/openvpn-credentials.txt

redirect-gateway def1
persist-key
persist-tun
nobind
cipher AES-256-CBC
ncp-disable
auth SHA256
explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5

dhcp-option DNS 8.8.8.8
dhcp-option DNS 1.1.1.1

ca /etc/openvpn/custom/ca.crt

cert /etc/openvpn/custom/client.crt

key /etc/openvpn/custom/client.key

inactive 3600
ping 10
ping-exit 60
resolv-retry 15
verb 3
remap-usr1 SIGTERM
; status failure

Current Behavior

Been trying to get this to work for a few days, following different examples/guides/yt videos and can't seem to figure out what the issue is.

Container starts up, then just dies.

Have found a few issues and resolved them (folder path issues for the cert files in the default.ovpn file for example)

Expected Behavior

It to launch, start transmission and be able to connect to it off my private ip 192.168.1.110:9091

Connecting to the container should be able to run curl ifconfig.me and get the vpn ip, where running it from my nas should give my isp ip.

How have you tried to solve the problem?

Have not tired other releases (not really sure how, just started trying to use docker as my old windows pc I had running cyberghost vpn (gui) started crashing, so trying to move it over to my nas).

Have been able to install transmission on its own using mariushostings script

and this works fine, able to load it up, download test torrents etc. Connecting to the container everything seems to work.

docker exec -it 9e53b64d4d37 /bin/bash root@9e53b64d4d37:/# curl ifconfig.me xx.xx.xx.xx root@9e53b64d4d37:/# ping google.com PING google.com (216.239.38.120): 56 data bytes 64 bytes from 216.239.38.120: seq=0 ttl=117 time=20.202 ms

Script that is working if i enable the network interface i setup using the same cyberghost vpn files (on the nas itself) which then routes all traffic out the vpn. If I enable the vpn interface, then run the same curl, i do get my vpn IP, so it does route it that way, it just breaks all my ddns links and I have to use the private IP to connect.

docker run -d --name=transmission \
-p 9091:9091 \
-p 51413:51413 \
-p 51413:51413/udp \
-e PUID=1026 \
-e PGID=100 \
-e TZ=America/Phoenix \
-e USER=admin \
-e PASS=adminadmin \
-v /volume1/docker/transmission/data:/config \
-v /volume1/docker/transmission/downloads:/downloads \
-v /volume1/docker/transmission/watch:/watch \
--restart always \
ghcr.io/linuxserver/transmission

Log output

Issue looks to be from dns lookup but not sure what setting to change next to test.

docker logs --details transmission-openvpn
 Starting container with revision: b33d0fe4c938259a0d4eb844e55468f387456121
 WARNING: initial DNS resolution test failed
 Creating TUN device /dev/net/tun
 Using OpenVPN provider: CUSTOM
 Modifying /etc/openvpn/custom/default.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
 Modification: Updating status for config failure detection
 Setting OpenVPN credentials...
 adding route to local network 192.168.1.0/24 via 172.19.0.1 dev eth0
 2023-03-20 11:04:13 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
 2023-03-20 11:04:13 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
 2023-03-20 11:04:13 WARNING: file '/etc/openvpn/custom/client.key' is group or others accessible
 2023-03-20 11:04:13 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 14 2022
 2023-03-20 11:04:13 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
 2023-03-20 11:04:13 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
 2023-03-20 11:04:23 RESOLVE: Cannot resolve host address: 87-1-us.cg-dialup.net:443 (Temporary failure in name resolution)
 2023-03-20 11:04:33 RESOLVE: Cannot resolve host address: 87-1-us.cg-dialup.net:443 (Temporary failure in name resolution)
 2023-03-20 11:04:48 RESOLVE: Cannot resolve host address: 87-1-us.cg-dialup.net:443 (Temporary failure in name resolution)
 2023-03-20 11:05:03 RESOLVE: Cannot resolve host address: 87-1-us.cg-dialup.net:443 (Temporary failure in name resolution)
 2023-03-20 11:05:03 Could not determine IPv4/IPv6 protocol
 2023-03-20 11:05:03 SIGTERM[soft,init_instance] received, process exiting

HW/SW Environment

- OS:synology 918+ NAS running DSM7
- Docker:20.10.3-1308

network I created in docker to test this is vpn_net 172.19.0.0/16, home network nas is on is 192.168.1.0/24 if that's needed

Anything else?

Image from cyberghost where I downloaded the files after creating it, using that username/password combo in the docker script

It wouldn't be an issue for me to post them since I can just delete it after and make a new one, if that will help with testing.

Each time i try to run it, i'll delete the docker after it fails and then try to make slight tweaks to it, then just run the whole script again to see if i get a different log.

image

recontwo commented 1 year ago

Been messing around with it and asking chatgpt questions, posting the script and asking if theres anything wrong.

Here are the results

image

image

I already had this flag in there, as well as in my default.opvn...so wasn't sure what else to test. Did try switching to 1.1.1.1.

image

image

I tried the command initially, and it gave a 127.0.0.11 ip initially for name server, then figured...why not switch the network back to the default one

image

and for some reason, if container is on the vpn_net it stops/crashes the app, but if i switch it to bridge it stays up...i can docker into it and when I run the curl

image

I had previously created the vpn_net network using the docker command, not via the docker gui interface...not sure what the difference is, but just created a new one called vpnnet, swapped the container over, and deleted vpn_net.

Started the app and it still crashed..

Moved it back over to the default bridge network, started app and it stays up and gets a valid vpn ip

image

So I guess the question is...whats the difference between the bridge network, and a new one i manually create? Is there something else new ones don't have that the default does? I've been wracking my brain against this and if i had just left it default I could have had it working days ago?... any input would be great. If i do move other containers over, they do stay working...so no idea what to do from here to check but hopefully my mess helps someone else check things out.

recontwo commented 1 year ago

Closing out issue as main issue was resolved. Will have to research why the new network created in docker does not work for it, but does for other dockers (tested by moving a few of my other ones and they still worked).