docker-transmission-openvpn Transmission cannot connect to UDP trackers.

Transmission cannot connect to UDP trackers.

Open HeyBanditoz opened this issue 2 years ago • 29 comments

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, [email protected]
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

Mar 05 '22 21:03 HeyBanditoz

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.

Mar 08 '22 21:03 sokulski

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?

Mar 09 '22 00:03 HeyBanditoz

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

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

Mar 09 '22 18:03 sokulski

Same here :/ UDP trackers are all failing

Mar 13 '22 06:03 DB-CL

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

Mar 18 '22 03:03 kyleinprogress

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

Mar 18 '22 12:03 pkishino

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.

Mar 19 '22 02:03 evanroheff21

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

Mar 19 '22 14:03 addiebarron

@addiebarron same issue with PIA

Apr 14 '22 01:04 jordanbaucke

Another with PIA

Apr 15 '22 01:04 theharleyquin

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.

Apr 15 '22 03:04 sokulski

It looks like I have this issue on Mullvad fwiw

Apr 24 '22 23:04 stephen304

Experiencing the same issue with ExpressVPN.

Apr 25 '22 16:04 froggyball

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

Apr 30 '22 04:04 Denist79

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

May 02 '22 21:05 herlon214

Also having this issue with PIA

May 06 '22 22:05 bennettn404

Windscribe seems to be suffering through the same.

May 28 '22 18:05 whizzzkid

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

Jun 07 '22 03:06 tarbychark

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

Jun 12 '22 18:06 vinchi007

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.

Jun 12 '22 18:06 vinchi007

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.

Jun 17 '22 05:06 aprice-dev

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.

Jun 20 '22 18:06 five2seven

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

Setting ENABLE_UFW=false doesn't appear to help

Jun 25 '22 20:06 dsbert

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.

Jun 25 '22 20:06 dsbert

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

Jul 01 '22 14:07 philippjess

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.

Jul 03 '22 05:07 geodanah

Tried both alone and together, sadly does not help.

Jul 03 '22 20:07 philippjess

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.

Jul 21 '22 00:07 dsbert

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.

Aug 26 '22 02:08 eumario

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 [email protected] \
-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

Oct 09 '22 09:10 RetroDreams

docker-transmission-openvpn docker-transmission-openvpn copied to clipboard

Transmission cannot connect to UDP trackers.

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

Current Behavior

Expected Behavior

How have you tried to solve the problem?

Log output

HW/SW Environment

Anything else?

docker-transmission-openvpn
docker-transmission-openvpn copied to clipboard