Add link to qbittorrent-gluetun-port-update

[TechnoSam]

Thank you for maintaining this project! I really wanted to use qBittorrent with Gluetun, but I couldn't find any way to automatically update the forwarded port, so I made one myself. If you're using docker-compose, it's really easy to add this additional container to the deployment and keep the port up to date.

https://hub.docker.com/r/technosam/qbittorrent-gluetun-port-update

https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update

Hopefully this can be helpful to others who find themselves in my situation. Please let me know if there's any changes you'd like to see!

[DrFrankensteinUK]

Hey @TechnoSam - Can I ask does this container find the open port for any provider and update it into qbit? As that would be great!

[TechnoSam]

@DrFrankensteinUK What do you mean by provider? VPN provider?

It will work with anything Gluetun supports. It uses the control HTTP API. As long as Gluetun is making it available there, it will work. I don't think that's every VPN, but it is most of them. I'll have to check the documentation, but you can check too, it may take me a minute.

[DrFrankensteinUK]

OK I think I get it, it's asking Gluetun what the forwarded port is and then applying that to qbit.

So if for example I set the firewall port forward variable for Gluetun of 44444 your container would map that into qbit saving me a step in setup.

Or is there some kind of additional activity taking place to find an open port on the vpn connection which can be used for qbit.

I suppose this matters more for vpn providers who randomise which port you are given on connection vs something like AIRVPN who give you a dedicated port.

[TechnoSam]

I'm not sure about the firewall, I would have to do some research to figure out if that's relevant.

But yes, forwarding is the primary use cases. Services like ProtonVPN and PIA don't give you a fixed port like AirVPN or Windscribe. If you don't know what the forwarded port will be, Gluetun exposes that in the control server, and my container reads that and sends it to qBittorrent.

[socketbox]

Not to detract from your work in any way, but I recently came across a bash script that does something similar: https://gist.github.com/fizzxed/958d8cdfa4dad8a97651afce4d74efce

And this as well: https://github.com/AlbyGNinja/port-sync

[patrickaclark]

Thank you for maintaining this project! I really wanted to use qBittorrent with Gluetun, but I couldn't find any way to automatically update the forwarded port, so I made one myself. If you're using docker-compose, it's really easy to add this additional container to the deployment and keep the port up to date.

https://hub.docker.com/r/technosam/qbittorrent-gluetun-port-update

https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update

Hopefully this can be helpful to others who find themselves in my situation. Please let me know if there's any changes you'd like to see!

Seems like everyone is getting in on varied implementations of this. I just spun up my own docker image to do this as well forking someone elses repo as I saw it in a forum post to get the firewall issue fixed when using Proton. Then I realized gluetun had the control server and the API where the repo I found was using a file internally to find the port, so I wrote a very similar script. Guess it was a good way to learn how to build docker images, and get some learning about Github.
Guess I should have checked the pull requests first 🤣

[t-anc]

It's a bit off-topic, but I've done somehing similar, but I took a different approach. Instead of a separate container, I've made a docker mod for Linuxserver's qbittorrent image. Here's the link if someone is interrested : https://github.com/t-anc/GSP-Qbittorent-Gluetun-sync-port-mod.

And it seems that qdm12 is thinking about a built-in solution for that, so I guess it will make other external ones obseletes (#75 (comment)).