gluetun: Bug: Docker containers sometimes become inaccessible when using "network_mode:" via gluetun VPN container

Is this urgent?: Yes

#################################################################################

Host OS

Synology NAS DSM
Docker via Portainer

root@Synology:~# uname -a; uname -K                     # BSD
Linux Synology 4.4.59+ #25426 SMP PREEMPT Mon Dec 14 18:48:50 CST 2020 x86_64 GNU/Linux synology_apollolake_718+


Portainer version # 2.1.1

root@Synology:~# docker-compose --version
docker-compose version 1.24.0, build 0aa59064

root@Synology:/var/packages/Docker/target/usr/bin# docker-compose --version
docker-compose version 1.28.5, build c4eb3a1f

CPU arch or device name: Intel amd64

What VPN provider are you using: PIA

What are you using to run your container?: Docker Compose

What is the version of the program

Netdata:
v1.29.3-129-nightly

qBittorrent:
version-14.3.3.99202101191832-7248-da0b276d5ubuntu20.04.1 | 01 Mar 2021 at 04:16:07

#################################################################################

What’s the problem 🤔 Docker containers become inaccessible when using "network_mode:" via gluetun VPN container

Note: Maybe this RFE I already created for some time would fix the issue? https://github.com/qdm12/gluetun/issues/386

The only way to resolve the issue, is by manual restart for the container

#################################################################################

**log

For example, last logs for netdata:

2021-03-14 01:36:19: tc-qos-helper.sh: WARNING: Cannot find file '/etc/netdata/tc-qos-helper.conf'.,
2021-03-14 01:36:19: tc-qos-helper.sh: WARNING: Cannot find file '/usr/lib/netdata/conf.d/tc-qos-helper.conf'.,
2021-03-14 01:36:19: tc-qos-helper.sh: WARNING: FireQoS is not installed on this system. Use FireQoS to apply traffic QoS and expose the class names to netdata. Check https://github.com/netdata/netdata/tree/master/collectors/tc.plugin#tcplugin,
2021-03-14 01:36:02: 20125: 266 '[localhost]:52060' 'DATA' (sent/all = 3664/3664 bytes -0%, prep/sent/total = 3.66/0.19/3.85 ms) 200 '/api/v1/info',
2021-03-14 01:36:02: 20125: 266 '[localhost]:52060' 'DISCONNECTED',
2021-03-14 01:36:02: 20125: 266 '[localhost]:52060' 'CONNECTED',
2021-03-14 01:35:02: 20124: 254 '[localhost]:50938' 'DATA' (sent/all = 3664/3664 bytes -0%, prep/sent/total = 5.44/0.64/6.08 ms) 200 '/api/v1/info',
2021-03-14 01:35:02: 20124: 254 '[localhost]:50938' 'CONNECTED',
2021-03-14 01:35:02: 20124: 254 '[localhost]:50938' 'DISCONNECTED',
2021-03-14 01:34:02: 20123: 254 '[localhost]:49944' 'DATA' (sent/all = 3664/3664 bytes -0%, prep/sent/total = 3.89/0.29/4.18 ms) 200 '/api/v1/info',
2021-03-14 01:34:02: 20123: 254 '[localhost]:49944' 'DISCONNECTED',
2021-03-14 01:34:02: 20123: 254 '[localhost]:49944' 'CONNECTED',
2021-03-14 01:33:02: 20122: 264 '[localhost]:49020' 'DATA' (sent/all = 3664/3664 bytes -0%, prep/sent/total = 4.79/0.20/4.99 ms) 200 '/api/v1/info'

For example, last logs for qBittorrent:

qt.network.ssl: QSslSocket::startClientEncryption: cannot start handshake on non-plain connection

#################################################################################

### Notes: I already created github bugs for those two products, but it only happens when I use the network mode with gluetun container, so I thought would be better to create the bug here.

netdata https://github.com/netdata/netdata/issues/10764

qBittorrent https://github.com/linuxserver/docker-qbittorrent/issues/105

You can find in both docker compose stack I used for each and troubleshooting steps taken.

Thanks

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 22 (10 by maintainers)

Most upvoted comments

This is not fixed yet. Every couple of days I have to manually redeploy my *arr stacks which are connected to gluetun network.

Squizzy911 on Dec 15, 2022

No that’s just for the vpn server side port forwarding which didn’t answer within 30 seconds, probably a problem on PIA server side I’d say. Closing the issue then thanks!

qdm12 on Apr 25, 2021

You are about the termination check, I misworded that.

So to be clear the gluetun container (not openvpn inside) never restarts by itself right? It only restart when it’s told to right?

Also maybe try with docker compose version ‘3’ maybe that helps for the networking part between containers.

I still need to research how to restart the container and the other connected container on a health check.

I would advise you not to, I’ll code that auto-healing in the coming days/2 weeks, it shouldn’t be too hard to develop.

qdm12 on Mar 15, 2021

Thanks for the update @qdm12

Answers:

Yes, gluetun container still working and no errors in the logs. (Do you wish to run that command when the issue happens again?)
Yes, restarting the containers using gluetun container as it’s network. gluetun already gets restarted automatically by itself.
I haven’t tried to run them all on the same docker compose. Do you think that would resolve the issue to have them all running on the same docker compose?

I just upgraded gluetun container to the latest release and both containers are running

https://github.com/qdm12/gluetun/releases/tag/v3.15.0

Ran the command

/ # wget -qO- https://ipinfo.io
{
  "ip": "172.98.92.85",
  "city": "Toronto",
  "region": "Ontario",
  "country": "CA",
  "loc": "43.7001,-79.4163",
  "org": "AS46562 Performive LLC",
  "postal": "M5N",
  "timezone": "America/Toronto",
  "readme": "https://ipinfo.io/missingauth"
}/ #

I will update when the issue happens again, soon.

ansred on Mar 14, 2021