Routing Containers Through a VPN

vpn-image.png

vpn-route.md

Moved to https://virtualize.link/vpn/

I may be wrong, but AFAIK depends_on may not be required because network_mode adds already a dependency

I would also add an explanation of the PostUp and PostDown commands. e.g.:

The post commands add a killswitch using iptable rules to prevent connections on other interfaces. Connections from LAN networks are still allowed to be able to connect to the services in the containers.

Additionally for Routing qBittorrent Through the VPN:

If the container gets accessed only from a docker network (e.g. a reverse proxy, sonarr, radarr, ...), connected to the vpn/wireguard container, expose can be used instead of ports to prevent access from outside. e.g.:

vpn:
    image: ghcr.io/linuxserver/wireguard
    container_name: vpn
    ...
    networks:
      - reverse-proxy
    expose:
      - "8080"  #qBittorrent

Thanks for the comments!
I'm also unsure about depends_on, I guess it doesn't hurt to keep it there.
I added the description to PostUp/Predown.
Regarding Expose, I wanted to stay in-line with the qBittorrent container documentation which recommends opening the port on the host, I guess advanced users know it's not needed when using a reverse proxy.

Hi all, I'm having the same issue and glad to have run into this. However, the above didn't help me.
I'm running a bunbutux container, and have containers routed through working perfectly.

I'm just setting up SWAG today, and any containers not routed through are fine, but the ones that are do not work. I tried to edit the .conf as per your instructions, and replaced the container name with the VPN name, and regardless, I keep getting host not found in the logs! Any thoughts?

Hey stx8, tag me on Discord and I'll try to help.

I'd like to add an Troubleshooting section:

Troubleshooting

Can't connect to the Web-UI of connected containers

This can be an issue if you don't use the killswitch implementation from Connecting the Wireguard Client to the VPN. These are implemented in PostUp and PreDown.

The ip table rules from Mullvad (and possible other providers) reject access from LAN networks.
The iptable rules implemented with the commands in PostUp and PreDown from this guide should work with accessing the container from within a LAN network.

Regarding:

Regarding Expose, I wanted to stay in-line with the qBittorrent container documentation which recommends opening the port on the host, I guess advanced users know it's not needed when using a reverse proxy.

Maybe it could be added in the notes section. Without ports or expose the vpn container does not know that qBittorrent (or any other service) listens on those ports because they aren't declared in the Dockerfile. I had to troubleshoot a bit myself when I've dealt with it the first time.

Edit: I've tried to write the section regarding expose instead of ports myself, but had slightly difficulties explaining why you need to specify expose, instead just expecting everything to work without both expose and ports:

Notes

...

Exposing ports of services only in docker networks

By exposing ports of services using ports, they are not only available to other containers on a shared docker network, but also from the host or even another machine if no additional firewall rules prevent access.
It is required to specify all required ports using expose because docker needs to know which ports are to be accessed. This is not required with "normal" containers because the list of exposed ports is already set in the Dockerfile.
If this is unwanted, another option is to use expose instead of ports to expose the ports only on connected docker networks:

vpn:
   image: ghcr.io/linuxserver/wireguard
   container_name: vpn
   ...
   networks:
     - reverse-proxy
   expose:
     - "8080"  #qBittorrent