ANSWERED Gluetun: Port forwarding works for an hour

[Blatantly0156 2]

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 10307]

@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 value of HEALTH_VPN_DURATION_INITIAL config option / environment variable, 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 2]

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

[sirjmann92 0]

You could also run a script to check if the port is open, and if it's not restart the stack, then notify you via webhook.

Create a script file, put the below code in it (modify the CONFIGURATION section for your environment), make the file executable, then put it on a cron schedule (I check mine every 15 minutes, been running like this for a few months). I use Cronicle as my cron scheduler (it's nice using a single application to manage scheduling for multiple servers), but you could use crontab if you want simplicity.
 

#!/bin/sh

# CONFIGURATION
GLUETUN_CONTAINER="gluetun"
FORWARDED_PORT=YourForwardedPort
COMPOSE_DIR="/your/gluetun/docker/compose/directory"
WEBHOOK_URL="https://discord.com/api/webhooks/yourDiscordChannelWebhook"

# Get current VPN IP from inside the container using wget
VPN_IP=$(docker exec "$GLUETUN_CONTAINER" wget -qO- https://ipinfo.io/ip)

# Verify that we got an IP
if [ -z "$VPN_IP" ]; then
    echo "$(date) - ERROR: Could not retrieve VPN IP from container $GLUETUN_CONTAINER." >&2
    exit 1
fi

# Check if port is open using nc, suppressing nc's own output
if nc -z -w3 "$VPN_IP" "$FORWARDED_PORT" >/dev/null 2>&1; then
    echo "$(date) - Port $FORWARDED_PORT on $VPN_IP is open and reachable."
else
    echo "$(date) - Port $FORWARDED_PORT on $VPN_IP is closed. Restarting stack..."
    cd "$COMPOSE_DIR"
    docker compose down
    sleep 5
    docker compose up -d

    # Notify via Webhook about the restart
    curl -X POST -H "Content-Type: application/json" \
        -d '{"content":"VPN port forwarding failed. Gluetun stack restarted to repair the issue."}' \
        "$WEBHOOK_URL"

    echo "$(date) - Stack restarted in $COMPOSE_DIR due to port $FORWARDED_PORT being closed."
fi

[Daniel15 14]

On 9/23/2024 at 6:38 AM, Blatantly0156 said:

I fixed by delaying the health check to 2 minutes.

You'll still have issues if the AirVPN node you're using is ever down for more than 2 minutes. 

Someone in the reddit thread suggested configuring your dependent container to restart whenever Gluetun's health check fails, which seems reasonable to me. 

<dependent-container>:
    depends_on:
      gluetun:
        condition: service_healthy
        restart: true