Hi all!

 

Since a long time I have been looking for a solution for the following problem: I have several dockers that I want to have behind a VPN. To that purpose I have a GlueTun VPN docker. The other dockers are using the network of the VPN docker by adding special parameter "--net=container:gluetunvpn". This works like a charm.

 

However, when the GlueTun VPN docker is updated or restarted, (obviously) the network of all depended dockers becomes invalid. After the restarting of the VPN docker, the depended dockers show 'Rebuild ready' but are stuck in that state. The only way that I am aware of to trigger the actual rebuilding of those dockers, is by browsing to the  /docker overview in de WebUI. Once I do that, all these dockers start the actual rebuild. If I do not visit that URL, none of the dockers gets rebuild and remain stuck in their 'Rebuild ready' state. As such, part of my system becomes unresponsive as those dockers cannot be reached anymore.

 

Is here any solution to this? Thanks in advance!

 

Regards, Michiel

anyone?

On 5/11/2024 at 1:23 PM, michielvv said:

Is here any solution to this? Thanks in advance!

If it is updated the complete container network is rebuilt by default, it could be however be the case that your server is not quick enough to establish the VPN connection but even if this is the case that shouldn't be an issue.

 

However if you restart the VPN container, you have to restart all attached containers too.

 

To circumvent that I built something that I call Connected Containers into my OpenVPN-Client and containers that may be attached to a VPN (for example SABnzbd, Radarr, Sonarr,...) so that the connected containers automatically restart after a certain amount of time if the OpenVPN-Client is restarted so that the containers actually have a network.

I know that might not help in your case because you are using GlutenVPN which I've never looked into.

 

There should be a script out there which you can run as a User Script which checks periodically the uptime from the containers and compares them, if it differs a huge amount of time it triggers a restart from all containers.

I'll see if I can source the script somewhere but I'm not too sure if I can find it because I read about that a few years ago.

 

EDIT: https://github.com/DyonR/docker-passthroughvpn?tab=readme-ov-file#installing-the-auto-restart-script

Thanks so much! I indeed think there may be some kind of race condition between the VPN connection complete and the rebuilding trigger for the VPN dependent dockers. << would this be a bug?

 

The script works like a charm. I have followed the above instructions, renamed the PASSTHROUGHVPNNAME to the containernetwork named 'gluetunvpn'. It does work a little different from your explanation though: it just checks if the VPN container has been restarted based on uptime and container id change (if it cannot get the uptime it assumes a container restart). If so, then it will restart all containers that rely on the network of the VPN container. Simple and clean solution, nice!

On 5/16/2024 at 2:15 AM, michielvv said:

Thanks so much! I indeed think there may be some kind of race condition between the VPN connection complete and the rebuilding trigger for the VPN dependent dockers. << would this be a bug?

 

The script works like a charm. I have followed the above instructions, renamed the PASSTHROUGHVPNNAME to the containernetwork named 'gluetunvpn'. It does work a little different from your explanation though: it just checks if the VPN container has been restarted based on uptime and container id change (if it cannot get the uptime it assumes a container restart). If so, then it will restart all containers that rely on the network of the VPN container. Simple and clean solution, nice!

Does this script still work for you? I changed the PASSTHROUGHVPNNAME to GluetunVPN (the name of my gluetun container), but the script doesn't do anything - nothing is printed to logs, and the script just seems to "run" indefinitely, never finishing.

I went through the script, and with my minimal CLI knowledge stepped through the commands to see what was happening, and they each worked. So I'm not clear why this won't run for me.

Edited October 20, 2025Oct 20 by lostinspace

Hi!

I actually decided at some point to use "Rebuild-DNDC", which works like a charm. There is one catch where restarting the docker containers behind the VPN went orphan: the dockers behind the VPN mostly have ports explicitly configured. However, I have set Network Type to 'None' on those dockers. That is a combination that will not work (Docker will give you an error). The Unraid GUI seems to silently ignore those port settings when choosing the Network Type 'None' and successfully starts when pressing 'Apply'. Rebuild-DNDC will not and so tries to restart the docker with Network Type 'None' AND port configs. That fails.

My solution was to remove the port configs from the dockers behind the VPN, so that Rebuild-DNDC successfully restarts those dockers with valid parameter combinations.

Thanks, I'll give it a shot.

I can't even start/restart connected containers via SSH UNTIL the Unraid Docker GUI page is loaded. Its so strange. Once I load the Docker tab, I can SSH restart containers and they come up. Same with Unraid Mobile app on IOS - can't start/restart any of the containers when they go down from an update or backup of the gluetun container, UNTIL I load the Unraid Docker GUI, then I can start the containers via the app.

Super strange. I hope Rebuild DNDC is the answer because this is driving me nuts. I noticed when I just spun up Rebuild DNDC it said GluetunVPN container EndpointID doesn't match and that it was rebuilding. Maybe this will solve whatever issues I have. Also in reviewing the Rebuild DNDC logs, I see

/usr/bin/docker: Error response from daemon: conflicting options: port publishing and the container type network mode.

See '/usr/bin/docker run --help'.

/usr/bin/docker: network "container:GluetunVPN" is specified multiple times.

See '/usr/bin/docker run --help'.

So I wonder if the source of my headaches are incorrectly configured child containers or something.

Edited November 11, 2025Nov 11 by lostinspace

I also created a script for that. Check it out:
https://gist.github.com/gmantoha/ba6418f3d24dccb9f09264423acff9ae