I’m setting up a self-hosted stack with a bunch of services running on a home device. I’m also tunneling all the traffic through a VPS in order to expose the services without exposing my home IP or opening ports on my local network. Currently all my traffic is HTTP, and its path looks like this:
- Caddy proxy on remote VPS (HTTPS, :80 & :443)
- Wireguard tunnel
- Caddy proxy in Docker on homeserver (HTTP, :80)
- app containers in separate isolated subnets, shared with Caddy
I want to set up qBittorrent and other torrent apps, and I want all their traffic to pass through the proxies. Proxying traffic to the WebUI is easy, there’s plenty of tutorials; what I’m struggling with is proxying the torrent leeching and seeding traffic, which is the most important part since I live in a country that’s not cool with piracy.
Unless I’m misunderstanding, BitTorrent traffic is TCP or UDP, so I’d need Caddy to act as a Layer 4 proxy. There’s a community-maintained plugin that should support this. How would I configure it though? Do I need both instances to listen on a new port? Or can I open a new port on the VPS only, and forward traffic to the homeserver Caddy over the same port as the HTTP traffic (:80)? Are there nuances in proxying TCP traffic that I should be aware of?
You must log in or register to comment.
Since you already have wireguard you don’t need any proxies, just set up wireguard to route through the VPS and you should be good to go.
Or you could install a proxy server on the VPS and enter those settings into qBittorrent, if you don’t want to use wireguard as a default route.
By “set up wireguard to route through the VPS” you mean having wireguard forward a port from the VPS to a port on the homeserver at its wireguard IP address?
qBittorrent will still need to publish the right IP address to peers though, right? So I will need to configure the proxy VPS’s IP address in qBittorrent…
Also that means binding a port on the qBittorrent container directly to the homeserver localhost. I’ve managed to keep the app containers isolated so far and it’d be nice to keep that, but if proxying the traffic is too annoying I guess I can just say fuck it and go with it.
What you describe doesnt really make sense so ill suggest what i think you really want;
You want your vps to be the wireguard server, the local PC connects as a client this “proxies” your connection so torrent swarms see the IP of your vps.
If you want port forwarding it gets a bit complicated because you need to forward the vps port over wireguard, but this is optional so you dont have to worry if you can’t figure it out.
Caddy doesn’t really seem relevant unless you want to have a domain name that forwards to your home network.
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…
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol NAT Network Address Translation SSL Secure Sockets Layer, for transparent encryption TCP Transmission Control Protocol, most often over IP TLS Transport Layer Security, supersedes SSL UDP User Datagram Protocol, for real-time communications VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting)
[Thread #981 for this sub, first seen 20th Sep 2024, 10:15] [FAQ] [Full list] [Contact] [Source code]
I think what you’re trying to do is called a VPN. Set up a VPN that tunnels all the torrent traffic to and from the virtual server.
That’s Wireguard, no?
Yes I already have that set up with Wireguard, what I’m figuring out is how to route traffic through it.
A) Set up a wiregard VPN server in your remote instance. Or better, get a VPN provider, the VPS is kinda pointless.
B) Assuming you’re using docker as you should to run your home server’s service, use gluetun to connect to the VPN and route your docker traffic for the instances through gluetun. This will ensure that you have a dead man switch when/if the VPN goes down.
C) set-up a reverse proxy to access the various instance from the outside if that is something you need.
Here’s a fully developed config, you can use a jumping point.
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.
Usually that’s done by the network routing. Add a default(?) route(?) or make the software bind to the vpn interface. I’m not sure. I think firewall rules can do the same thing. If you’re using docker, I’d advise you to use “gluetun” that seems to do everything for you.
Usually people do copyright violation with bittorrent. That means they tend to make sure the routing or dns doesn’t leak anything. I think that’s usually done by running the software inside of some containers or virtualization. If you do that your setup becomes simpler than inventing a dozen or so firewall rules. Either use gluetun or make the container bind to the vpn in its entirety. So practically the same setup everyone uses for pirating, just that you don’t pay for a VPN service, but do that (server) part yourself on your virtual server. Everything else is a good bit more elaborate and complicated…
