Transmission cannot connect to UDP trackers.

HeyBanditoz commented 2 years ago

Is there a pinned issue for this?

[X] I have read the pinned issues and could not find my issue

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

[X] I have searched the existing issues
[X] I have searched the existing discussions

Is there any comment in the documentation for this?

[X] I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

[X] I have checked the provider repo for issues
[X] My issue is NOT related to a provider

Are you using the latest release?

[X] I am using the latest release

Have you tried using the dev branch latest?

[X] I have tried using dev branch

Docker run config used

docker-compose.yml:

---
version: '3.3'
services:
  transmission-openvpn:
    container_name: transmission
    cap_add:
      - NET_ADMIN
    dns:
      - 1.1.1.1
      - 1.0.0.1
    networks:
      - services
    sysctls:
      - 'net.ipv6.conf.all.disable_ipv6=1'
    volumes:
      - '/zpool/nas/torrent:/data/torrent'
      - '/zpool/nas/plex/movies:/data/movies'
      - '/zpool/nas/plex/tvshows:/data/tvshows'
      - '/zpool/nas/iso:/data/iso'
      - '/zpool/ctpersist/transmission:/data/transmission-home'
      - './transmission-pre-start.sh:/scripts/openvpn-pre-start.sh:ro'
    environment:
      - OPENVPN_PROVIDER=PIA
      - OPENVPN_CONFIG=uk_london
      - OPENVPN_USERNAME=<redacted>
      - OPENVPN_PASSWORD=<redacted>
      - LOCAL_NETWORK=192.168.0.0/24
      - TRANSMISSION_DOWNLOAD_DIR=/data/tvshows
      - TRANSMISSION_RPC_USERNAME=<redacted>
      - TRANSMISSION_RPC_PASSWORD=<redacted>
      - TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
      - TRANSMISSION_UMASK=18
      - TRANSMISSION_PORT_FORWARDING_ENABLED=true
      - PUID=123
      - PGID=321
    image: haugene/transmission-openvpn:latest
    restart: always
    # this looks wonky, but it's so the migrated resume files will work without much work still.
    entrypoint: [ "bash", "-c", "mkdir /mnt/plex && ln -s /data/tvshows /mnt/plex/tvshows && ln -s /data/movies /mnt/plex/movies && ln -s /data/torrent /mnt/torrent; dumb-init /etc/openvpn/start.sh" ]

networks:
  services:
    driver: bridge
    name: services

And the customized transmission-pre-start.sh script that installs Transmission 3.00:

#!/bin/bash
# see https://github.com/haugene/docker-transmission-openvpn/discussions/1937
wget -O 976b5901365c5ca1.key "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xa37da909ae70535824d82620976b5901365c5ca1"

cat > /etc/apt/sources.list.d/transmission.list <<EOF
# Transmission PPA https://launchpad.net/~transmissionbt/+archive/ubuntu/ppa
deb [signed-by=/976b5901365c5ca1.key] http://ppa.launchpad.net/transmissionbt/ppa/ubuntu focal main
#deb-src http://ppa.launchpad.net/transmissionbt/ppa/ubuntu focal main
EOF

apt update -o Dir::Etc::sourcelist="sources.list.d/transmission.list" -o Dir::Etc::sourceparts="-" -o APT::Get::List-Cleanup="0"
apt install -y transmission-daemon transmission-cli

Current Behavior

Transmission is not connecting to UDP trackers, only TCP (HTTP) ones.

Example: T77KY.

When I run qBittorrent on my desktop, I see this over the VPN; it's able to query a tracker's DNS server: Wireshark_WMjFighTpj

...and then talk to it. Notice the IP from the DNS response are the same. (This was captured on my desktop with working qBittorrent, again) Wireshark_MoAkYEFc2S

When I run tcpdump on the non-working Transmission container, there is no UDP communication except for DNS requests.

The command I used to run tcpdump on the container: docker run --rm --cap-add=NET_ADMIN --cap-add=NET_RAW --net container:transmission -it nicolaka/netshoot tcpdump -i tun0 -n -w /dump.cap ...and to copy it out of the container while it's running: docker cp container_id:dump.cap dump.cap

Expected Behavior

I would expect Transmission to be able to connect to UDP trackers.

How have you tried to solve the problem?

Use dev image instead of latest
Use cap_add: ALL instead of cap_add: NET_ADMIN
Change net.ipv6.conf.all.disable_ipv6=1 to 0
- Outright remove that line
Use TCP-based OpenVPN PIA configurations instead of UDP-based ones
Remove the PUID=123 PGID=321 lines
Use Transmission 2.94 instead of Transmission 3.00
Use latest Transmission from git (compiled beforehand)
Restart the host machine
Remove the custom DNS servers
Swap OpenVPN config files
Disable port forwarding completely
Set env var TRANSMISSION_BIND_ADDRESS_IPV6='fe80::
Set env var DISABLE_PORT_UPDATER=true

Log output

[2022-03-05 09:18:09.174] Bound socket 16 to port 53831 on 10.25.112.119 (net.c:462)
[2022-03-05 09:18:09.175] Bound socket 17 to port 53831 on :: (net.c:462)
[2022-03-05 09:18:09.175] Port Forwarding (NAT-PMP) readnatpmpresponseorretry failed. Natpmp returned -7 (the gateway does not support nat-pmp); errno is 111 (Connection refused) (natpmp.c:77)
[2022-03-05 09:18:09.175] Port Forwarding State changed from "Starting" to "???" (port-forwarding.c:106)
[2022-03-05 09:18:10.176] Couldn't connect socket 40 to 2400:adc1:43f:0:78e7:d442:5c59:5c21, port 47600 (errno 99 - Cannot assign requested address) (net.c:339)

Container logs

``` mkdir: cannot create directory '/mnt/plex': File exists Starting container with revision: 20877f1b168b6ff27fc58aeef40756572c562d47 Executing /scripts/openvpn-pre-start.sh --2022-03-05 09:40:44-- https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xa37da909ae70535824d82620976b5901365c5ca1 Resolving keyserver.ubuntu.com (keyserver.ubuntu.com)... 162.213.33.8, 162.213.33.9 Connecting to keyserver.ubuntu.com (keyserver.ubuntu.com)|162.213.33.8|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1379 (1.3K) [text/plain] Saving to: '976b5901365c5ca1.key' 0K . 100% 219M=0s 2022-03-05 09:40:44 (219 MB/s) - '976b5901365c5ca1.key' saved [1379/1379] WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Hit:1 http://ppa.launchpad.net/transmissionbt/ppa/ubuntu focal InRelease Reading package lists... Building dependency tree... Reading state information... All packages are up to date. WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Reading package lists... Building dependency tree... Reading state information... transmission-cli is already the newest version (3.00-1ubuntu1~20.04.1). transmission-daemon is already the newest version (3.00-1ubuntu1~20.04.1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. /scripts/openvpn-pre-start.sh returned 0 Creating TUN device /dev/net/tun Using OpenVPN provider: PIA Running with VPN_CONFIG_SOURCE auto Provider PIA has a bundled setup script. Defaulting to internal config Executing setup script for PIA Downloading OpenVPN config bundle openvpn into temporary file /tmp/tmp.tidFYxD3On Extract OpenVPN config bundle into PIA directory /etc/openvpn/pia Starting OpenVPN using config uk_london.ovpn Modifying /etc/openvpn/pia/uk_london.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.0.0/24 via 172.22.0.1 dev eth0 Sat Mar 5 09:40:45 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021 Sat Mar 5 09:40:45 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 Sat Mar 5 09:40:45 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sat Mar 5 09:40:45 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]143.244.39.18:1198 Sat Mar 5 09:40:45 2022 Socket Buffers: R=[212992->212992] S=[212992->212992] Sat Mar 5 09:40:45 2022 UDP link local: (not bound) Sat Mar 5 09:40:45 2022 UDP link remote: [AF_INET]143.244.39.18:1198 Sat Mar 5 09:40:45 2022 TLS: Initial packet from [AF_INET]143.244.39.18:1198, sid=e7e68e60 d4ad292d Sat Mar 5 09:40:45 2022 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Sat Mar 5 09:40:45 2022 VERIFY OK: depth=1, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, emailAddress=secure@privateinternetaccess.com Sat Mar 5 09:40:45 2022 VERIFY KU OK Sat Mar 5 09:40:45 2022 Validating certificate extended key usage Sat Mar 5 09:40:45 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Sat Mar 5 09:40:45 2022 VERIFY EKU OK Sat Mar 5 09:40:45 2022 VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=london401, name=london401 Sat Mar 5 09:40:46 2022 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA Sat Mar 5 09:40:46 2022 [london401] Peer Connection Initiated with [AF_INET]143.244.39.18:1198 Sat Mar 5 09:40:47 2022 SENT CONTROL [london401]: 'PUSH_REQUEST' (status=1) Sat Mar 5 09:40:47 2022 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.17.112.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.17.112.77 255.255.255.0,peer-id 2,cipher AES-128-GCM' Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: timers and/or timeouts modified Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: compression parms modified Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: --ifconfig/up options modified Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: route options modified Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: route-related options modified Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: peer-id set Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: adjusting link_mtu to 1625 Sat Mar 5 09:40:47 2022 OPTIONS IMPORT: data channel crypto options modified Sat Mar 5 09:40:47 2022 Data Channel: using negotiated cipher 'AES-128-GCM' Sat Mar 5 09:40:47 2022 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key Sat Mar 5 09:40:47 2022 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key Sat Mar 5 09:40:47 2022 ROUTE_GATEWAY 172.22.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:16:00:02 Sat Mar 5 09:40:47 2022 GDG6: remote_host_ipv6=n/a Sat Mar 5 09:40:47 2022 ROUTE6: default_gateway=UNDEF Sat Mar 5 09:40:47 2022 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options Sat Mar 5 09:40:47 2022 OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/3 Sat Mar 5 09:40:47 2022 TUN/TAP device tun0 opened Sat Mar 5 09:40:47 2022 TUN/TAP TX queue length set to 100 Sat Mar 5 09:40:47 2022 /sbin/ip link set dev tun0 up mtu 1500 Sat Mar 5 09:40:47 2022 /sbin/ip addr add dev tun0 10.17.112.77/24 broadcast 10.17.112.255 Sat Mar 5 09:40:47 2022 /etc/openvpn/tunnelUp.sh tun0 1500 1553 10.17.112.77 255.255.255.0 init Up script executed with tun0 1500 1553 10.17.112.77 255.255.255.0 init Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.17.112.77 Updating Transmission settings.json with values from env variables Using existing settings.json for Transmission /data/transmission-home/settings.json Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 10.17.112.77 Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /data/tvshows Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /data/incomplete Overriding port-forwarding-enabled because TRANSMISSION_PORT_FORWARDING_ENABLED is set to true Overriding rpc-authentication-required because TRANSMISSION_RPC_AUTHENTICATION_REQUIRED is set to true Overriding rpc-password because TRANSMISSION_RPC_PASSWORD is set to [REDACTED] Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091 Overriding rpc-username because TRANSMISSION_RPC_USERNAME is set to user Overriding umask because TRANSMISSION_UMASK is set to 18 Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch sed'ing True to true Enforcing ownership on transmission config directories Applying permissions to transmission config directories Setting owner for transmission paths to 123:321 Setting permissions for download and incomplete directories Mask: 022 Directories: 755 Files: 644 Setting permission for watch directory (775) and its files (664) ------------------------------------- Transmission will run as ------------------------------------- User name: abc User uid: 123 User gid: 321 ------------------------------------- STARTING TRANSMISSION Provider PIA has a script for automatic port forwarding. Will run it now. If you want to disable this, set environment variable DISABLE_PORT_UPDATER=true Transmission startup script complete. Sat Mar 5 09:40:47 2022 /sbin/ip route add 143.244.39.18/32 via 172.22.0.1 Sat Mar 5 09:40:47 2022 /sbin/ip route add 0.0.0.0/1 via 10.17.112.1 Sat Mar 5 09:40:47 2022 /sbin/ip route add 128.0.0.0/1 via 10.17.112.1 Sat Mar 5 09:40:47 2022 WARNING: OpenVPN was configured to add an IPv6 route over tun0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected. Sat Mar 5 09:40:47 2022 Initialization Sequence Completed Running functions for token based port fowarding Reserved Port: 56902 Sat Mar 5 09:40:54 UTC 2022 transmission auth required waiting for transmission to become responsive transmission became responsive setting transmission port to 56902 localhost:9091/transmission/rpc/ responded: "success" Checking port... Port is open: Yes ####################### SUCCESS ####################### Port: 56902 Expiration Fri May 6 21:37:11 UTC 2022 ####################### Entering infinite while loop Every 15 minutes, check port status ```

HW/SW Environment

OS: Ubuntu 20.04 Linux hayden-nas 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Docker: Docker version 20.10.12, build e91ed57

I do have a non-standard networking setup with my box, here's the associated netplan:

network:
        version: 2
        renderer: networkd
        ethernets:
                enp8s0:
                        dhcp4: no
                        dhcp6: no
                enp7s0:
                        dhcp4: no
                        dhcp6: no
        bridges:
                vmbr0:
                        interfaces:
                                - enp7s0
                        addresses:
                                - 192.168.0.136/24
                        gateway4: 192.168.0.1
                        nameservers:
                                addresses:
                                - 192.168.0.1

The other unused Ethernet device is being used as macvtap in passthrough mode to a VM for means of a virutalized firewall.

Anything else?

No response

sokulski commented 2 years ago

I'm experiencing the same thing. I've tried using PIA and NordVPN thus far.

HTTP(S) trackers load consistently, while UDP trackers fail consistently.

HeyBanditoz commented 2 years ago

I'm experiencing the same thing. I've tried using PIA and NordVPN thus far.

HTTP(S) trackers load consistently, while UDP trackers fail consistently.

@sokulski What's the networking setup of your host machine, out of curiosity?

sokulski commented 2 years ago

@HeyBanditoz Forgive me... Not sure what specifically you'd like to know.

My Docker host is an OMV box with a static IP address.

DB-CL commented 2 years ago

Same here :/ UDP trackers are all failing

kyleinprogress commented 2 years ago

Running into the same issue. No UDP trackers are connecting.

 transmission:
    image: haugene/transmission-openvpn:latest
    container_name: transmission
    cap_add:
      - NET_ADMIN
    dns:
      - 1.1.1.1
      - 1.0.0.1
    environment:
      - OPENVPN_PROVIDER=PIA
      - PIA_OPENVPN_CONFIG_BUNDLE=openvpn
      - OPENVPN_CONFIG=ca_toronto,ca_montreal,ca_vancouver
      - OPENVPN_USERNAME=xxxxxxxxxxxxxxxxxxxxxxx
      - OPENVPN_PASSWORD=xxxxxxxxxxxxxxxxxxxxxxxx
      - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
      - LOCAL_NETWORK=192.168.10.0/24
      - PUID=${PUID}
      - PGID=${PGID}
      - TRANSMISSION_DOWNLOAD_DIR=/downloads/transmission
      - TRANSMISSION_INCOMPLETE_DIR=/incomplete
      - TRANSMISSION_DOWNLOAD_QUEUE_SIZE=50
      - TRANSMISSION_PEER_LIMIT_GLOBAL=2000
      - TRANSMISSION_PEER_LIMIT_PER_TORRENT=200
      - TRANSMISSION_RATIO_LIMIT=2
      - TRANSMISSION_RATIO_LIMIT_ENABLED=true
      - TRANSMISSION_IDLE_SEEDING_LIMIT=11520
      - TRANSMISSION_IDLE_SEEDING_LIMIT_ENABLED=true
    ports:
      - 9091:9091
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /opt/appdata/transmission:/data
      - /mnt/disks/t01/transmission/:/incomplete
      - /mnt/storage/downloads/:/downloads
    devices:
      - /dev/net/tun:/dev/net/tun

When I connect to VPN via my desktop and launch transmission, the UPD trackers connect fine. Connecting to the same VPN server and requesting port forwarding, so not sure what the issue is.

Only difference I can find is transmission is 2.94 in docker and 3.00 on my desktop.

I did notice that I can connect on some ports:

Screen Shot 2022-03-17 at 10 39 05 PM

pkishino commented 2 years ago

hmm, im using privatevpn with 2.94 dev branch and have no problems using udp trackers here

evanroheff21 commented 2 years ago

Add me to the list of those who cannot connect to udp:// trackers. I literally set up for the first time today, on latest branch in docker on synology DSM. I'm using IVACY as my VPN provider, and tried a few different configs including udp and tcp profiles, different countries, etc. Peers do connect over the one http:// tracker, but my speed maxes at ~ 1 MB/s.

addiebarron commented 2 years ago

I'm experiencing this too, with PIA. @evanroheff21 are you using PIA too?

jordanbaucke commented 2 years ago

@addiebarron same issue with PIA

theharleyquin commented 2 years ago

Another with PIA

sokulski commented 2 years ago

I was on PIA. I’ve since switched to NordVPN and my issues went away.

I think the issues stem from PIA’s handling of DNS.

On Apr 14, 2022, at 6:34 PM, Kyle McPherson @.***> wrote:

Another with PIA

— Reply to this email directly, view it on GitHub https://github.com/haugene/docker-transmission-openvpn/issues/2209#issuecomment-1099773208, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWNZEKUA77K7KLP27AZHU3VFDBTJANCNFSM5QAFAFSA. You are receiving this because you were mentioned.

stephen304 commented 2 years ago

It looks like I have this issue on Mullvad fwiw

froggyball commented 2 years ago

Experiencing the same issue with ExpressVPN.

Denist79 commented 2 years ago

Yep same here with Mullvad. Does anyone know what the fix is or is this something to do with Mullvad

herlon214 commented 2 years ago

I had it working with Mullvad totally fine (even port forward), today I restarted the container and it's not working anymore. Container doesn't even start anymore:

Mon May  2 21:02:40 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Mon May  2 21:02:40 2022 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Mon May  2 21:02:40 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon May  2 21:02:40 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]185.65.134.143:1195
Mon May  2 21:02:40 2022 Socket Buffers: R=[212992->425984] S=[212992->425984]
Mon May  2 21:02:40 2022 UDP link local: (not bound)
Mon May  2 21:02:40 2022 UDP link remote: [AF_INET]185.65.134.143:1195
Mon May  2 21:03:40 2022 [UNDEF] Inactivity timeout (--ping-exit), exiting
Mon May  2 21:03:40 2022 SIGTERM[soft,ping-exit] received, process exiting

bennettn404 commented 2 years ago

Also having this issue with PIA

whizzzkid commented 2 years ago

Windscribe seems to be suffering through the same.

tarbychark commented 2 years ago

Also having the same issue using PIA. Was running fine, then restarted Docker a few days ago and the issue occurred afterwards.

vinchi007 commented 2 years ago

I'd suggest disabling firewall that comes with this docker image and retest

vinchi007 commented 2 years ago

I had it working with Mullvad totally fine (even port forward), today I restarted the container and it's not working anymore. Container doesn't even start anymore:

Mon May  2 21:02:40 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Mon May  2 21:02:40 2022 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Mon May  2 21:02:40 2022 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon May  2 21:02:40 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]185.65.134.143:1195
Mon May  2 21:02:40 2022 Socket Buffers: R=[212992->425984] S=[212992->425984]
Mon May  2 21:02:40 2022 UDP link local: (not bound)
Mon May  2 21:02:40 2022 UDP link remote: [AF_INET]185.65.134.143:1195
Mon May  2 21:03:40 2022 [UNDEF] Inactivity timeout (--ping-exit), exiting
Mon May  2 21:03:40 2022 SIGTERM[soft,ping-exit] received, process exiting

I think you're having a different issue. Folks reporting UDP connectivity failure to trackers, not about UDP tunnel to VPN provider. I'd suggest to report a separate issue and provide all necessary logs, config etc.

aprice-dev commented 2 years ago

I'm also experiencing this issue on PIA. I'm able to download the torrents just fine from the machine natively, even with PIA connected, but the container isn't connecting to any of the UDP trackers.

five2seven commented 2 years ago

Same issue here on ProtonVPN. To be honest though, I’m pretty sure I’ve never been able to connect to UDP trackers since setting this up a couple of years ago. My speeds have always been poor, even though speeds through the same VPN connection outside the container are great.

dsbert commented 2 years ago

I'd suggest disabling firewall that comes with this docker image and retest

Setting ENABLE_UFW=false doesn't appear to help

dsbert commented 2 years ago

I was on PIA. I’ve since switched to NordVPN and my issues went away. I think the issues stem from PIA’s handling of DNS.

Trying with PEER_DNS=false doesn't appear to help either.

philippjess commented 2 years ago

I have the same problem with Mullvad, all UDP connections to trackers are failing. Host reboot helps for a short while.

geodanah commented 2 years ago

I had this problem for several weeks using PIA and this container, but it resolved itself once I enabled 2 things in Transmission: "peer-port-random-on-start": true, "port-forwarding-enabled": true,

Not sure if one or both are required, but it allowed me to start using UDP trackers again.

philippjess commented 2 years ago

Tried both alone and together, sadly does not help.

dsbert commented 2 years ago

I had this problem for several weeks using PIA and this container, but it resolved itself once I enabled 2 things in Transmission: "peer-port-random-on-start": true, "port-forwarding-enabled": true,

Not sure if one or both are required, but it allowed me to start using UDP trackers again.

This did seem to help me. Still have some trackers failing over UDP, but many are working now, so it might be something specific to those trackers.

eumario commented 1 year ago

I had this problem for several weeks using PIA and this container, but it resolved itself once I enabled 2 things in Transmission: "peer-port-random-on-start": true, "port-forwarding-enabled": true,

Not sure if one or both are required, but it allowed me to start using UDP trackers again.

Yep, had the same problem, and doing this solved the issue as well.

RetroDreams commented 1 year ago

I had this problem while running the docker setup through a Synology NAS with Nord.

Was able to fix it finally (after trying 20 different suggestions) by running the docker container with --cap-add=ALL

The only way to add an argument like this in Synology Docker is by creating the container via a scheduled task through the control panel (and selecting root user to run the task), rather than using Synology's built-in UI (which is very limited in function).

My full scheduled task (after container is created I can start/stop it from the normal UI):

docker create --cap-add=ALL \
-v /volume1/storage/transmission:/data \
-v /volume1/storage/transmission:/config \
-e OPENVPN_CONFIG=us \
-e OPENVPN_PROVIDER=NORDVPN \
-e NORDVPN_COUNTRY=US \
-e NORDVPN_CATEGORY=legacy_p2p \
-e OPENVPN_USERNAME=email@domain.com \
-e OPENVPN_PASSWORD=password \
-e OPENVPN_OPTS= \
--log-driver json-file \
--log-opt max-size=10m \
--name transmission \
-p 9091:9091 \
haugene/transmission-openvpn:dev

d4g79 commented 1 year ago

still have this issues tried the above here is my config. Using OMV 5 pORTAINER and Mullvad. Rarbg just magnetizing torrent and it stay like that.

version: "3.4" services: transmission-openvpn: image: haugene/transmission-openvpn:latest container_name: transmission-openvpn restart: always cap_add:

ALL volumes:
blank
blank environment:
CREATE_TUN_DEVICE=true
OPENVPN_PROVIDER=MULLVAD
OPENVPN_CONFIG=se_got
OPENVPN_USERNAME=
OPENVPN_PASSWORD=
LOCAL_NETWORK=192.168.2.0/24
- OVERRIDE_DNS_1=8.8.8.8

- OVERRIDE_DNS_2=8.8.4.4
PEER_DNS=false
OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
PUID=1000
PGID=100
TZ=Australia/Sydney
TRANSMISSION_BLOCKLIST_ENABLED=true
TRANSMISSION_BLOCKLIST_URL=https://github.com/Naunter/BT_BlockLists/raw/master/bt_blocklists.gz
TRANSMISSION_DOWNLOAD_DIR=/torrents/complete
TRANSMISSION_INCOMPLETE_DIR=/torrents/incomplete
TRANSMISSION_WATCH_DIR=/torrents/watch
TRANSMISSION_WEB_UI=combustion
TRANSMISSION_PEER_LIMIT_GLOBAL=1200
TRANSMISSION_PEER_LIMIT_PER_TORRENT=240
TRANSMISSION_SCRAPE_PAUSED_TORRENTS_ENABLED=false
TRANSMISSION_DHT_ENABLED=false
TRANSMISSION_PEX_ENABLED=false
TRANSMISSION_PEER_PORT=60614
TRANSMISSION_PORT_FORWARDING_ENABLED=true
TRANSMISSION_SCRIPT_TORRENT_DONE_ENABLED=true
TRANSMISSION_SCRIPT_TORRENT_DONE_FILENAME=/data/unrar.sh
TRANSMISSION_UMASK=0 logging: driver: json-file options: max-size: 10m ports:
9091:9091
8888:8888 dns:
208.67.222.222
208.67.220.220 sysctls:
net.ipv6.conf.all.disable_ipv6=0

kencinder commented 1 year ago

I was having this same problem too, and I tried EVERYTHING stated above, nothing worked until I used the Google DNS servers.

https://haugene.github.io/docker-transmission-openvpn/tips-tricks/#use_google_dns_servers

jumblies commented 1 year ago

I too was struggling mightily with this and added the following to docker-compose.yaml

  dns:
    - 8.8.8.8
    - 8.8.4.4
  environment: #added to other env vars
    - ENABLE_UFW=false
    #  "peer-port-random-on-start": true, "port-forwarding-enabled": true,
    - TRANSMISSION_PEER_PORT_RANDOM_ON_START=true
    - TRANSMISSION_PORT_FORWARDING_ENABLED=true

After these changes, about 50% of udp trackers were working with PIA.

elisimpson commented 1 year ago

Me too with Nord VPN. Nord is connected with UDP, don't know if that could be related.

Wouldn't using Google's DNS servers kind of defeat the purpose of using a VPN? Google would have the IP of every connection?

HeyBanditoz commented 1 year ago

Me too with Nord VPN. Nord is connected with UDP, don't know if that could be related.

Wouldn't using Google's DNS servers kind of defeat the purpose of using a VPN? Google would have the IP of every connection?

No, just that you tried to look up which IP address a domain is associated with.

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] commented 1 year ago

Feel free to re-open this issue if you think it deserves another look.

haugene / docker-transmission-openvpn