Closed HeyBanditoz closed 1 year 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.
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?
@HeyBanditoz Forgive me... Not sure what specifically you'd like to know.
My Docker host is an OMV box with a static IP address.
Same here :/ UDP trackers are all failing
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:
hmm, im using privatevpn with 2.94 dev branch and have no problems using udp trackers here
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.
I'm experiencing this too, with PIA. @evanroheff21 are you using PIA too?
@addiebarron same issue with PIA
Another with PIA
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.
It looks like I have this issue on Mullvad fwiw
Experiencing the same issue with ExpressVPN.
Yep same here with Mullvad. Does anyone know what the fix is or is this something to do with Mullvad
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
Also having this issue with PIA
Windscribe seems to be suffering through the same.
Also having the same issue using PIA. Was running fine, then restarted Docker a few days ago and the issue occurred afterwards.
I'd suggest disabling firewall that comes with this docker image and retest
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.
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.
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.
I'd suggest disabling firewall that comes with this docker image and retest
Setting ENABLE_UFW=false
doesn't appear to help
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.
I have the same problem with Mullvad, all UDP connections to trackers are failing. Host reboot helps for a short while.
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.
Tried both alone and together, sadly does not help.
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.
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.
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
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:
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
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.
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?
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.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Feel free to re-open this issue if you think it deserves another look.
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-compose.yml
:And the customized
transmission-pre-start.sh
script that installs Transmission 3.00:Current Behavior
Transmission is not connecting to UDP trackers, only TCP (HTTP) ones.
Example:![T77KY.](https://i.banditoz.io/T77KY.png)
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](https://user-images.githubusercontent.com/7574664/156876599-b7a56000-7fd9-484e-bc7f-91c2286664fd.png)
...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](https://user-images.githubusercontent.com/7574664/156876615-1500823a-b8f2-4e02-a506-e75850ebbd24.png)
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?
dev
image instead oflatest
cap_add: ALL
instead ofcap_add: NET_ADMIN
net.ipv6.conf.all.disable_ipv6=1
to0
PUID=123
PGID=321
linesTRANSMISSION_BIND_ADDRESS_IPV6='fe80::
DISABLE_PORT_UPDATER=true
Log output
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
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
I do have a non-standard networking setup with my box, here's the associated netplan:
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