andscape
Idk man, it seems pretty irresponsible to me to write a blogpost with stuff that you got from ChatGPT without understanding it. People will assume that if you wrote a blogpost on this then you know what you’re doing. ChatGPT gets stuff wrong all the time, and we’re talking about firewall configuration here. If it misconfigured some stuff it could leave you and your readers vulnerable to all kinds of shit.
In this case it seems to me that (luckily) there’s just a bunch of redundant routing, but the next time it could be leaking your and your readers’ torrent traffic out of the VPN tunnel, leaving you vulnerable to legal repercussions for piracy.
Please don’t authoritatively post stuff that you got from the automatic bullshit generator without understanding it.
Nice, I recently went through the same struggle of setting up this configuration based on that LinuxServer post. My main nitpick on this is that automating the ip route configuration for the qBittorrent container is a pretty important step which is not explained in the post. Leaving any manual steps in any Docker setup is pretty bad practice.
Since you’re using LinuxServer’s QBT image a good way to do this is to make use of their standard custom init scripts. You can just mount a script with the ip route commands to /custom-cont-init.d/my-routes.sh:ro on the container and it will be run automatically on each startup.
Another nitpick is that the PostDown commands in the wireguard configs are useless since you’re running them in Docker.
Wow thank you, this is the most useful reply I’ve received so far!
This means I don’t need to mess around with QBT’s “proxy” settings? I was pretty confused since the only options available are SOCKS/SOCKS5 and HTTP, but I’m guessing that’s a different kind of proxy than what I need…
I indeed have a domain name pointing to the VPS IP, with Caddy managing TLS. Other apps are exposed this way, and I will do the same for the qBittorrent WebUI as well. I like having Caddy as a single gateway where I can apply security configs and monitor all traffic, I was hoping I would be able to pass torrent traffic through it as well but everybody seems very much against it.
I already have wireguard setup as you describe so I guess I’ll just give up on passing torrent traffic through the proxies and just open a localhost port on the qBittorrent container…
Resetting the “time since last being told I don’t know shit on the internet” back to 0 once again…
I already have an existing and working setup used for other apps, it’s close to the one described in this blogpost. Yes, it’s complicated and inefficient, but it has reasons to be. I want to keep my qBittorrent configuration as close to this setup as reasonably possible for consistency. If your point is that it’s counterproductive to follow this setup then… fair enough. I can just route traffic from the VPS to an exposed port on the local qBittorrent container over Wireguard, but that wasn’t my preferred solution.
Running a torrent client through a proxy doesn’t isolated a process.
I was talking about network isolation, not process isolation.
make sure your traffic is routing there properly
That was pretty much what I was asking for help with.
I have already set up all of that. My setup is similar to the one in this blogpost and it’s already working for various apps that only use HTTP. What I’m trying to do is to also route BitTorrent traffic (TCP/UDP) over the same setup without opening up entirely new paths.
I’m guessing what you mean is setting up port forwarding in Wireguard…
The thing is ideally I would want all connections in and out of my homeserver’s Docker network to go through the local Caddy proxy, so the app containers are isolated. That still means having at least the local Caddy acting as a TCP proxy, even if the VPS Caddy is bypassed. If that’s too much of a hassle though I can instead just expose a port on the qBittorrent container directly to the homeserver’s localhost, and forward that with wireguard to the VPS.
