Fresh Port Assignment

[GHOSCHT]

Hey! I'm currently running Transmission using Haugene's Docker-Transmission container. Since you're redeveloping the entire application according to #7 I was thinking about the handling of port assignments. If the new port is the same one as before, everything should work without further hassle. However if the account is assigned a different port than before, the entire Docker/VPN container has to be restarted (at least from my experience). How do you handle this in your case?

If the reassignment happens before the 7 days the ephemeral port is valid for this will probably be no real problem. If the scheduled time is longer than 7 days it should be possible to mount /var/run/docker.sock and restart the VPN container (possibly even multiple containers, e.g. sonarr,prowlarr,... since docker doesn't restart depending containers) so that the VPN container can pick up the freshly assigned port.

[dumbasPL]

I've never considered this since the containers I've used always worked fine after updating the port in the torrent client. What is the reason behind needing to restart the container? I don't see any reason as to why a restart would be needed because I don't see any option to configure a port in the first place in the container you linked. In the containers I've used, I just needed to update the listening port and everything worked since the torrent client was listening directly on the VPN interface. If you could provide an MRE on how to reliably break your setup that would be nice.

I could add some kind of docker client but I don't think that would go very far because everybody has a slightly different setup and some setups may even require to completely re-create the container. But if you have any simple yet versatile ideas then I'm open to suggestions.

With the way things are currently set up in v3, you should be able to hack it together using the exec client that would execute a custom script with the new port as an argument. I've added it for this exact purpose, accommodating non-standard setups.

Also, just in case you misunderstood this project: This project already handles updating the port that the torrent client is using via their RPC/API interface. If you don't have any firewalls setup then this should work without needing to restart the container.

And just in case I misunderstood: Will transmission keep listening on the old port after you go into the web UI and change it? I'm asking if it (just the torrent client, not related to VPN or containers) needs a restart after changing the configuration or does it update on the fly?

[GHOSCHT]

Here's a way I can recreate this issue without any major time consumption:

    image: haugene/transmission-openvpn
    container_name: transmission
    restart: always
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - LOCAL_NETWORK=192.168.0.0/16
      - OPENVPN_PROVIDER=WINDSCRIBE
      - OVPN_PROTOCOL=udp
      - OPENVPN_USERNAME=xxxxxxx
      - OPENVPN_PASSWORD=xxxxxxx

1. Remove the port forwarding in the windscribe dashboard.
2. Restart the VPN container. The current port cannot be forwarded, since it's not opened by windscribe.
3. Re-create a matching port ephemeral forward in the windscribe dashboard and manually set it in the transmission settings. This can be the same as before or any other

Even after waiting for more than 20 minutes the new port isn't picked up. Transmission's built-in port forwarding tester always says it's closed. An external test with something like nmap verifies this. If the container is restarted after that it is recognized as open. This process simulates the effect of getting a different port from before without having to wait for a different matching ephemeral port assignment. At least from experience this behaves the same as with a fresh port assignment.

The same issue can be found in the following sources:

• https://www.reddit.com/r/Windscribe/comments/q5cydd/ephemeral_port_forwarding/
• https://windscribe.com/knowledge-base/articles/setting-up-port-forwarding, Step 4

Also, just in case you misunderstood this project: This project already handles updating the port that the torrent client is using via their RPC/API interface. If you don't have any firewalls setup then this should work without needing to restart the container.

I was aware of that. I was thinking about the case where you e.g. currently have port 12345 set and this project updates it to something like 54321 in the windscribe dashboard and transmission via rpc.

And just in case I misunderstood: Will transmission keep listening on the old port after you go into the web UI and change it? I'm asking if it (just the torrent client, not related to VPN or containers) needs a restart after changing the configuration or does it update on the fly?

Just checked it. I restarted the transmission daemon inside the container and the problem still persists, so it must be openvpn (or something else).

My overall intent of this issue was finding out if you were facing this limitation as well. Will it be possible to run both the transmission client and the exec client or is it limited to only one singular client? Because if I can run both (preferrably in some fixed order) I'll be able to fix this the hacky way.

[dumbasPL]

Ok, sorry for my ignorance, guess my setup was never stable enough for me to notice 😅

I did some testing and here is what I found

• On IKEv2 and OpenVPN the port forwarding gets set up once you connect and continues to work until you disconnect. Even after you remove/change the port in the web UI the forward will continue to work until you disconnect (tested for over 12 hours on OpenVPN)
• On wireguard, their website says that they don't support port forwarding but that's not 100% true. Back in the day, I asked them about and they said that they were working on it. Now when I tested it it seems to work fine but with a few caveats. Since wireguard doesn't really have a concept of a "connection" it's not as simple. From what I observed it will start working immediately if you haven't been connected for a while. so it seems to configure itself when the key exchange happens. This also means that this is the only protocol that will eventually (roughly every 2 minutes I believe) update itself without needing to restart anything because the keys change on a regular basis.

Now I'm actually interested in figuring out a way to give people a way to easily restart the containers. For docker, this would be relatively simple-ish but we would also need to restart all the containers that depend on the one we are restarting. This problem has already mostly been solved by watchtower, and in our case, it would be even simpler since we don't need to fully re-create the containers, just restart

PS: For other solutions like swarm, k8s, bare metal I'll just document the process of making custom scripts using the exec client and call it a day. My assumption is that if somebody has a setup like that they already know what they are doing and accommodating all the possible setups would be impossible anyway.