This is a plug-and-play solution bundling Transmission and the most common VPN configurations in a Docker container, ensuring that all torrent traffic goes via an active VPN connection. After configuring it, you just run "docker-compose up" and can then access Transmission via its web UI. It could be nice to have this built into the client, but using a container feels safer.

https://github.com/haugene/docker-transmission-openvpn

I’ve been using this for a while now, and it has been working like a charm!

For me, the real power of containers is that all the mistakes I could've made during the install are in ~a single file instead of a long forensic goose chase

This is a great container! Been using this for years. (I've contributed!)

The only downside is that @haugene has gone missing for sometime now, as such there are no firm releases. If you want new features/bug fixes, you have to pull dev, which isn't very ideal. Otherwise the maintainers are doing a great job (shout out to @pkishino!)

I have to agree with them, it’s antithetical to what torrent is about.

Depends on what torrent is about. For me, it is about watching shows that you can't officially watch where I live yet. Once I week, I hit up a site and, click a magnet link, and a couple of minutes later I can watch my favorite show. (The cost of the VPN is incidentally about the same as a streaming subscription. I think for this reason it is tolerated by the powers that be.)

I don't expect torrents to be available for a long time. Only very few people keep the torrent entry in their client alive for long, even though I keep around all the files. This is as opposed to eMule and older systems, where you can download any file in the user's media folder.

I believe the previous commenter meant that sequential downloads are orthogonal to the design of Bit Torrent.

>(The cost of the VPN is incidentally about the same as a streaming subscription. I think for this reason it is tolerated by the powers that be.)

I really don't follow you there

Why? It doesn't need to prevent concurrent uploading.

Superseeding (and whatever you would call it from the client point of view) allows for peer-to-peer broadcasting.

I run my torrent client in a container and have that container only go out the vpn. Works very well without screwing with computer wide network settings.

I'm using namespaced-openvpn to restrict transmission to one network and you could limit the amount of concurrently active files to one, effectively downloading them sequentially. Or do you want to download each file sequentially?

I would hazard they are asking for file-block sequential downloads from start of file to end, so they can start watching a movie while it is still downloading and be assured that the first parts of the moview are present without gaps ...

This goes against the general cluster inter-peer everybody swaps what they have so far w/out reference to file position for maximising transmission within a swarm design of the torrent protocol.

I’ve got a home lab with proxmox as the hypervisor. I’m running openwrt (x86) for my household router (in a qemu VM) and I’ve got transmission running in a (lxc) container. When the transmission container boots up, it gets its IP address via DHCP (server in openwrt). I configured dhcp to allocate the same lP address to the container every time. You could also just use a static ipconfig in the container.

Within openwrt, I’ve installed WireGuard and OpenVPN for accessing different vpns.

Finally, again in openwrt, I installed the policy based routing package[1]. This package makes it super easy to route all traffic from the transmission container to the VPN network.

There are probably many ways you could do this, but this setup is great for me!

1: https://docs.openwrt.melmac.net/pbr/

Sounds like a lot of fun, and a huge time sink.

Tldr: use OpenWRT to create a static IP reservation for a dedicated torrent instance, then use source-based routing to send traffic over a VPN running on the router.

Sounds pretty awesome. I've not dabbled with PBR on home equipment. We did use it in prior employment to force all PCI traffic over a dedicated physical network between datacenters.

Under Linux you can run transmission as another user and have an iptables rule to only allow outbound traffic through a specific interface.

Or as your user in a cgroup, probably.

Or just uidrange based policy for a separate routing table that just routes to the VPN. Just one thing to set up.

you don't even need the extra user: use a network namespace.

- ip netns add vpnonly # create an empty namespace

- ip netns exec vpnonly wg quick ... # connect to your VPN

later, launch transmission inside this namespace:

- ip netns exec vpnonly transmission

has the nice property that as long as you do that exec step right (or even half right), the failure mode is no connectivity rather than accidentally sending traffic in the clear.

If you don’t trust yourself to not make a mistake with firewall config, why do you trust yourself not to make one when setting up an allow list? One wrong digit or dot and you’ll be in the same place.

Start with a default policy of deny and work from there, if you’re only creating rules for allowing traffic explicitly then there’s less possibility for error.

It already has the ability to specify an IP address to bind to. I use an OpenVPN up script to stop any running instance, replace the bind address with the current VPN interface address and start an instance.

Not ragging on Transmission here but qbittorrent has zero problems getting out of my network and I didn't open up any ports or upnp either, give it a try. Transmission just has issues on my network that I don't care to figure out or open up ports for, qbit is quite good at navigating through NAT.

Lately I've noticed that public trackers are behind Cloudflare. If you're on a VPN, you have a high likelihood of getting the Cloudflare captcha. Your bittorrent client will be unable to scrape those trackers, or bootstrap DHT, etc because of the cloudflare block.

bitport.io cloud torrenting and done (after downloading at high speeds from their site), for me at least.

alternatively qbittorrent has this built in.

Agreed. Users shouldn't have to understand firewall rules, containers, VMs, or even VPNs in order to tunnel traffic for a specific app through a (more) trusted third party.

We need an open protocol for establishing tunnel/VPN connections. Apps implement the protocol, which lets you enter your tunnel provider and go through a quick OAuth flow to establish a tunnel. This would be a big win for VPN providers as well because people would be sending only specific traffic through them instead of everything.

Users should understand how to use their computer. Asking users to comprehend a firewall or a vpn (if using a vpn) is not unreasonable.

Coddling users is harmful.

Making secure practices simple (or automatic) for less-technical users is not “coddling”.

"Hey why are my torrent downloads running super slow?"

"Oh, well, your torrent client decided to automatically use your vpn because it saw one running and somebody decided that was the right behavior because they thought you were dumb."

Users have preferences. Users can read. Let them learn and sort it out. Don't ruin a simple program with tarred assumptions of what is correct for users. Prefer simplicity.

Also don't assume using a vpn is more secure. That is a wrong assumption.

I don't have a horse in this race, but I think you're presuming simplicity where there is none.

A bittorrent client, even in CLI form, is not simple software at all. Have you ever taken a look at the myriad of available settings?

Most GUI clients have a sort of "wizard" that helps you pick acceptable connection parameters. This feature alone has a truckload of assumptions coded in. And that kind of feature exists for a reason: no nonsense-seeking users. They're the majority. Just let me download my file bro.

It also makes sense that the developer chooses parameters. They are probably the person with the most detailed knowledge of the problem, they are probably the person who knows best what the parameters should be.

It baffles my mind when developers just expect users to tweak low level settings. Sure, it's good if stuff is configurable, but it should work correctly out of the box. Like, you spent days or weeks working on this feature, don't expect your users to do the same...

Yes, I agree that your assumptions about how you think I think this should work are bad. :^)

But to be more specific with my feedback, it seems a bit silly that Transmission (I'm trying 4.0.0b1 right now) doesn't allow me to specify that it must use "VPN X" (as opposed to "VPN Y", which is also available) for downloads.

I understand that I could mess with namespaces or containers or VMs and probably make that work, but "use Bittorrent client with VPN" is more or less a universal use case and should be straightforward.

Circa 1989 I remember people complaining that the NeXT computer (which eventually turned into the current Mac OS) was needlessly coddling users, and that anybody who wanted the power of Unix needed to know how to recompile their kernel. I also remember people objecting to MS Windows because people really should be using MS-DOS so that they understand what's going on.

The main point of computers is to make things easier for people. Most of us make our livings because computers are very good for that. If most users really had to deeply understand the technologies involved in solving their needs, a lot fewer of us would have jobs and much more time would be wasted by people who were just trying to get something done. So yes, let's absolutely coddle users.

The main point of computers is not to make it easier for people, that mindset leads us to cede control of our lives to technology.

The point of computing is to be a tool to make people more powerful and efficient, an extension of our abilities, able to do more or better.

Yes, I think we agree. That would fit within my definition of "things" in "make things easier". They can only do more/better with computers if the software is built to support them in that. If instead we insist that people focus on understanding the computer rather than doing the things they want to do, then they will do less and/or worse.

I would be fine with users doing less with their computers, if they in turn understood how they worked and why we all get angry here about things like: politicians likening cryptography to criminal activity, companies hoovering your data from every site you visit, etc.

I see. In what areas are you prepared to make the symmetrical deal? That you'll do less and get less while investing more time in understanding areas other people are less expert in?

I’ll cook more if we had less shitty pre made food in stores and less fast food. I could make several other examples but that’s just one I thought of.

There are millions of job openings for coders now. Illiteracy was not a good idea.

Also, youtube just served me an un-skip-able 12 minute add 30 seconds into a video. It was the 3rd add. The thought police is all over the web now. My windos cant download photos from my iphone. My windos is rebooting when it feels like it. The glued in phone battery life is garbage after 2 years. I must have purchased 30 chargers now. My new laptop requires a microsoft account. Google search is not working anymore. Adsense is driving up prices.

Its like trying to get nutrition from MacDonalds. The mc drive is convenient tho. Very easy for users.

This isn't about coddling users, it's about not reinventing the wheel.

Sure you could spend hours reading pf man pages. But maybe it would be better use of time if one person figures out how to do it, writes code to do it automatically, and shares that with other people so they can spend more time watching all the movies they download instead of configuring their bit torrent client.

users that don’t understand those things are doomed to make the wrong trust choices. vpns are decidedly not more trusted. differently trusted, sure.

Set http_proxy environment variable to a socks proxy that goes through the vpn. Some vpn clients offer a socksproxy built in. That way if the vpn is not connected the proxy address is dead.