haugene / docker-transmission-openvpn

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

Huge internet bandwidth drop when container is running #1417

Closed BackedUpBooty closed 3 years ago

BackedUpBooty commented 3 years ago

Describe the problem This may not be something you can fix, your container does what it says it does (so thank you!), this is more of a networking issue but I'm hitting brick walls.

I'm running a Synology NAS on 'router2' with DMZ enabled on 'router1' (public, what my ISP plugs into), main reason is my media server connects to router2 and all connections can be dedicated to streaming. Anyway: every time I start the container, regardless of how much bandwidth Transmission is using I lose almost all net bandwidth on both routers for all devices - when using my win10 machine, router2 retains some net connectivity (a test on speedtest.net shows a connection ping upwards of 1000 when it's normally 20-22) and it becomes almost impossible to connect via wifi to router1. Even when I'm LAN'd into router1, it won't load the router settings when connecting to default gateway. Super strange behaviour. I don't know if this has any bearing, but I get massive fluctuations in transmission DL speed - 2.5MB down to 114KB up to 1.3MB down to 9KB... I have a 320Mbps line which regularly speedtests to 250 on wireless connections, and I don't get this with other connections through my VPN provider.

As this only happens when your container is running (and didn't happen with other torrent+vpn containers I've tried) I wondered if there's something you could see which I can't. As it seemed originally more of a router problem, I tried disabling DMZ and just doing some port forwarding on both routers but that didn't change anything, nor did providing only static IP addresses for devices and disabling DHCP.

Add your docker run command

docker run \ --cap-add=NET_ADMIN \ --device=/dev/net/tun \ -d \ -v /volume1/docker/TorrentVPN/resolv.conf:/etc/resolv.conf \ -v /volume1/Media/NewtoSort:/data \ -e "OPENVPN_PROVIDER=PUREVPN" \ -e "OPENVPN_CONFIG=nl2-ovpn-udp" \ -e "OPENVPN_USERNAME=--------" \ -e "OPENVPN_PASSWORD=--------" \ -e "LOCAL_NETWORK=192.168.1.175/24" \ -e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60" \ -e FW_DISABLE_IPTABLES_REJECT=true \ -e "PGID=100" \ -e "PUID=1024" \ -p 9091:9091 \ --sysctl net.ipv6.conf.all.disable_ipv6=0 \ --name "transmission-openvpn-syno" \ haugene/transmission-openvpn:latest

I'd also followed the TUN.sh instructions which worked

Logs

Enforcing ownership on transmission config directories, Applying permissions to transmission config directories, Setting owner for transmission paths to :, Setting permission for files (644) and directories (755), Setting permission for watch directory (775) and its files (664), , -------------------------------------, Transmission will run as, -------------------------------------, User name: , User uid: , User gid: , -------------------------------------, , STARTING TRANSMISSION, NO PORT UPDATER FOR THIS PROVIDER, Transmission startup script complete., Sat Oct 24 02:27:15 2020 /sbin/ip route add 5.254.73.171/32 via 172.17.0.1, Sat Oct 24 02:27:15 2020 /sbin/ip route add 0.0.0.0/1 via 188.72.82.97, Sat Oct 24 02:27:15 2020 /sbin/ip route add 128.0.0.0/1 via 188.72.82.97, Sat Oct 24 02:27:15 2020 Initialization Sequence Completed, Sat Oct 24 02:53:40 2020 event_wait : Interrupted system call (code=4), Sat Oct 24 02:53:40 2020 SIGUSR1[hard,] received, process restarting, Sat Oct 24 02:53:40 2020 Restart pause, 3 second(s), Sat Oct 24 02:53:43 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts, Sat Oct 24 02:53:43 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]172.83.45.115:53, Sat Oct 24 02:53:43 2020 Socket Buffers: R=[212992->425984] S=[212992->425984], Sat Oct 24 02:53:43 2020 UDP link local: (not bound), Sat Oct 24 02:53:43 2020 UDP link remote: [AF_INET]172.83.45.115:53, Sat Oct 24 02:53:43 2020 TLS: Initial packet from [AF_INET]172.83.45.115:53, sid=8e9024be 73dbbd7a, Sat Oct 24 02:53:43 2020 VERIFY OK: depth=1, C=HK, ST=Central, L=HK, O=Secure-ServerCA, OU=IT, CN=Secure-ServerCA, name=Secure-ServerCA, emailAddress=mail@host.domain, Sat Oct 24 02:53:43 2020 VERIFY KU OK, Sat Oct 24 02:53:43 2020 Validating certificate extended key usage, Sat Oct 24 02:53:43 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication, Sat Oct 24 02:53:43 2020 VERIFY EKU OK, Sat Oct 24 02:53:43 2020 VERIFY OK: depth=0, C=HK, ST=Central, L=HK, O=Secure-Server, OU=IT, CN=Secure-Server, name=changeme, emailAddress=mail@host.domain, Sat Oct 24 02:53:44 2020 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1550', Sat Oct 24 02:53:44 2020 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM', Sat Oct 24 02:53:44 2020 WARNING: 'auth' is used inconsistently, local='auth SHA1', remote='auth [null-digest]', Sat Oct 24 02:53:44 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA, Sat Oct 24 02:53:44 2020 [Secure-Server] Peer Connection Initiated with [AF_INET]172.83.45.115:53, Sat Oct 24 02:53:45 2020 SENT CONTROL [Secure-Server]: 'PUSH_REQUEST' (status=1), Sat Oct 24 02:53:45 2020 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 172.94.19.3,dhcp-option DNS 172.94.19.5,sndbuf 393216,rcvbuf 393216,comp-lzo no,route-gateway 172.94.19.113,topology subnet,ping 10,ping-restart 120,ifconfig 172.94.19.124 255.255.255.240,peer-id 10,cipher AES-256-GCM', Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: timers and/or timeouts modified, Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: compression parms modified, Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified, Sat Oct 24 02:53:45 2020 Socket Buffers: R=[425984->425984] S=[425984->425984], Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: --ifconfig/up options modified, Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: route options modified, Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: route-related options modified, Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified, Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: peer-id set, Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: adjusting link_mtu to 1625, Sat Oct 24 02:53:45 2020 OPTIONS IMPORT: data channel crypto options modified, Sat Oct 24 02:53:45 2020 Data Channel: using negotiated cipher 'AES-256-GCM', Sat Oct 24 02:53:45 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key, Sat Oct 24 02:53:45 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key, Sat Oct 24 02:53:45 2020 Preserving previous TUN/TAP instance: tun0, Sat Oct 24 02:53:45 2020 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device., Sat Oct 24 02:53:45 2020 /sbin/ip route del 5.254.73.171/32, Sat Oct 24 02:53:45 2020 /sbin/ip route del 0.0.0.0/1, RTNETLINK answers: No such process, Sat Oct 24 02:53:45 2020 ERROR: Linux route delete command failed: external program exited with error status: 2, Sat Oct 24 02:53:45 2020 /sbin/ip route del 128.0.0.0/1, RTNETLINK answers: No such process, Sat Oct 24 02:53:45 2020 ERROR: Linux route delete command failed: external program exited with error status: 2, Sat Oct 24 02:53:45 2020 Closing TUN/TAP interface, Sat Oct 24 02:53:45 2020 /sbin/ip addr del dev tun0 188.72.82.100/28, Sat Oct 24 02:53:45 2020 /etc/openvpn/tunnelDown.sh tun0 1500 1553 188.72.82.100 255.255.255.240 init, Sat Oct 24 02:53:46 2020 ROUTE_GATEWAY 172.17.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:00:06, Sat Oct 24 02:53:46 2020 TUN/TAP device tun0 opened, Sat Oct 24 02:53:46 2020 TUN/TAP TX queue length set to 100, Sat Oct 24 02:53:46 2020 /sbin/ip link set dev tun0 up mtu 1500, Sat Oct 24 02:53:46 2020 /sbin/ip addr add dev tun0 172.94.19.124/28 broadcast 172.94.19.127, Sat Oct 24 02:53:46 2020 /etc/openvpn/tunnelUp.sh tun0 1500 1553 172.94.19.124 255.255.255.240 init, Up script executed with tun0 1500 1553 172.94.19.124 255.255.255.240 init, Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 172.94.19.124, Generating transmission settings.json from env variables, sed'ing True to true, Enforcing ownership on transmission config directories, Applying permissions to transmission config directories, Setting owner for transmission paths to :, Setting permission for files (644) and directories (755), Setting permission for watch directory (775) and its files (664), , -------------------------------------, Transmission will run as, -------------------------------------, User name: , User uid: User gid: , -------------------------------------, , STARTING TRANSMISSION, NO PORT UPDATER FOR THIS PROVIDER, Transmission startup script complete., Sat Oct 24 02:53:48 2020 /sbin/ip route add 172.83.45.115/32 via 172.17.0.1, Sat Oct 24 02:53:48 2020 /sbin/ip route add 0.0.0.0/1 via 172.94.19.113, Sat Oct 24 02:53:48 2020 /sbin/ip route add 128.0.0.0/1 via 172.94.19.113, Sat Oct 24 02:53:48 2020 Initialization Sequence Completed,

Host system:

Synology 920+ DSM 6.2.3-25426 update 2 Docker ver. 18.09.0-0513

ilike2burnthing commented 3 years ago

May not be the issue, but you should change: -e "LOCAL_NETWORK=192.168.1.175/24" to: -e "LOCAL_NETWORK=192.168.1.0/24"

BackedUpBooty commented 3 years ago

May not the issue, but you should change: -e "LOCAL_NETWORK=192.168.1.175/24" to: -e "LOCAL_NETWORK=192.168.1.0/24"

Thanks, good catch on that, but yeah wasn't a fix. It's super confusing. I could explore a different torrent/vpn container (I'd already used a qbittorrent/ovpn one) but I like the no frills on transmission. I tried changing the config file to the tcp version as well, but also no joy.

ilike2burnthing commented 3 years ago

I have an MTU of 1500 and use UDP, so I have added --mssfix 1472 to OPENVPN_OPTS. I wasn't having your issues, but it did make my download speed more stable. Might be worth a try for you at least.

BackedUpBooty commented 3 years ago

Thank you again.

I actually switched routers and used r1 as my LAN connection (annoying as all subnets had to be changed too) and... issue persisted.

So I started from scratch with TUN as well, but implemented this in a slightly different way using task scheduler to run the resolv.conf and the bash script. I also mapped the resolv.conf file to /etc/resolv.conf in the container using the docker GUI. All that together seemed to do the trick. Oh and I used the transmission web gui override but doubt that had an impact :)

I can't see any material changes in the log, except that username is now 'root' and the puid/guid are both set as 0.

Speeds are still highly variable, and port is closed

--mssfix 1472 to OPENVPN_OPTS

Do I insert this myself in the existing env line, or do I need to run the container again from latest image?

Cheers!

ilike2burnthing commented 3 years ago

Yea, just add it to that env line. It may not be necessary if you have everything working ok now, but it shouldn't harm anything.

BackedUpBooty commented 3 years ago

Great thanks. Don't suppose you've got any tips for closed port? Router port forwarding isn't making any difference, and although I found an issue from two years ago (#381 I think) it didn't really help me.

ilike2burnthing commented 3 years ago

You'd need to also add the port on the container's config with -p 51413:51413 or whatever port you use.

BackedUpBooty commented 3 years ago

Yeah to be honest I'd not done that because it never seemed to work before over here. I added it in and still got a closed port.

I could play around with this more and maybe I will in the future, but for now I'm just going to put this down to a case of 'being in Japan' and leave it there. Thanks for all your help.

ilike2burnthing commented 3 years ago

I'm not entirely sure, as this is an old link, but it looks like port forwarding is a paid addon for PureVPN - https://support.purevpn.com/article-categories/getting-started/windows/windows-old-software/nat-firewall

BackedUpBooty commented 3 years ago

Thanks again. You're right, and I had it, but looks like the add-on expired about the time I moved to Japan... didn't realize so I thought it was some random Japan thing (because there's tons of those to be fair). Anyway I got it back, port is now open. Cheers!

stale[bot] commented 3 years 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 3 years ago

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