this post was submitted on 07 Oct 2025
38 points (100.0% liked)

Selfhosted

52213 readers
743 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
38
Separate Docker stacks using gluetun networking (lemmy.world)
submitted 6 days ago by Dust0741@lemmy.world to c/selfhosted@lemmy.world
13 comments fedilink hide all child comments
 

I would like to run Gluetun in its own compose.yaml file, and run qbittorrent in its own compose.yaml file. I want to use the vpn connection Gluetun makes for qbittorrent.

Does anyone have examples of this working? I've been messing with the containers, and different docker networks can I cannot get it working.

(my test has been running docker exec -it qbittorrent curl -s https://ifconfig.me/)

you are viewing a single comment's thread
view the rest of the comments
[–] Selfhoster1728@infosec.pub 1 points 4 days ago

I had a problem similar to this and did not like the containers being binded to gluetun (problematic on docker daemon restarts, gluetun container being recreated, etc)

My solution was changing the gateway of each container to be routed through the tun. So first by having them both on the same internal network, then changing the entrypoint of the container I want tunneled to include the gateway change.

For example my entrypoint would be:

... && route del default && route add default gateway $GATEWAY_IP eth0

The container may be missing packages related to route so it may be necessary to modify the Dockerfile to install extra packages.

The reason the gateway must be set at the entrypoint is because docker overrides the gateway to correspond with the networking defined during container creation. And the entrypoint is the last thing executed before the container starts for realsies.

However gluetun also needs to work as a gateway which is done by modifying it's iptables post-up rules file (at /iptables/post-rules.txt). I appended at the beginning of the file the following rules:

iptables -A FORWARD -i eth0 -o tun0 -s 172.84.0.0/24 -d 0.0.0.0/0 -j ACCEPT iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

What this does is accept any traffic from the net I have my gluetun and other container in, then forwards outgoing traffic to eth0 from tun0, and vice versa for incoming.

Sorry for wall of text this is not very straight forward :(