ANSWERED Gluetun: Port forwarding works for an hour

[Blatantly0156 1]

I'm running into an issue here, and I'm not sure where to start exactly.
The problem is probably not new, it's only that I didn't notice it before.

Here's my setup:
Proxmox > Debian > Docker > Gluetun > Multiple Qbittorrent instances
Qbittorrents are routed through gluetun.

I noticed I didn't get much upload, although I'm seeding a lot and was looking into the problem. I tested if ports were open on the dashboard here and it said Connection Refused (111).
I did some troubleshooting which got me to restart the stack of gluetun and qbittorrents. I checked if ports are open: Yes! (I didn't change anything in the config by the way)

Yay, Problem solved I thought.

Only after a couple days, the same error: Connection Refused.

I tested again now and the same thing happened after an hour or so.

Any ideas?

Here's docker-compose and gluetun logs:
https://pastebin.com/g7xw5E2R

It looks like a firewall issue of some kind, but there's no firewall running on the debian system. Maybe it's a gluetun issue, but I want to ask here as well

Thanks in advance


 

[Staff 10111]

@Blatantly0156

Hello!

It sounds like you are experiencing this bug:
https://github.com/qdm12/gluetun/issues/1407

Note this: "It might be because there is a listener going through the tunnel, but gluetun destroys that tunnel on an internal vpn restart and re-creates it. I had the same issue with the http client fetching version info/public ip info from within gluetun, and the fix was to close 'idle connections' for the http client when the tunnel is up again". Therefore, unless something changed in Gluetun, an effective solution is restarting qBittorrent (the 1st workaround explained in the bug thread).

Also, try to increase the HEALTH_VPN_DURATION_INITIAL config option as various users reported that this change solved the problem.

If all of the above fails, try to bind qBittorrent to the actual tun interface and make sure you're running the latest qBittorrent version.

Anyway, not an AirVPN side problem, as you may be already aware of.

Kind regards
 

[Blatantly0156 1]

Thanks for the fast reply! I will look into it.

EDIT:
For future readers: the link above was exactly my problem. I fixed by delaying the health check to 2 minutes. Apparently this is used for OpenVPN only anyway. Since I use Wireguard it doesn't matter.
I added the following line to the environment in the gluetun docker-compose. 12 hours it's still running perfectly.

HEALTH_VPN_DURATION_INITIAL=120s

 

Edited ... by Blatantly0156
added my solution

[Gliglue 0]

It seems the healthcheck solution would be better though.
 

healthcheck:
    test: ["CMD-SHELL", "wget -qO- http://portcheck.transmissionbt.com/4330 | grep -q 1 || exit 1"]
    interval: 1m30s
    timeout: 10s
    retries: 3
    start_period: 40s

 

Edited ... by Gliglue