Bug: control server stays at 0 after forwarded port failure

[Flip7413]

Is this urgent?

No

Host OS

Ubuntu

CPU arch

x86_64

VPN service provider

ProtonVPN

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2026-03-01T12:05:08.834Z (commit ed26957)

What's the problem 🤔

I use proton VPN with a port forwarding forwarding setup. I lately changed my setup (upgrading from openvpn to wireguard, and I also moved the VPN to the netherlands). I noticed lately that after a while, Gluetun raises the error ERROR [port forwarding] adding port mapping: executing remote procedure call: reading from udp connection: read udp 10.2.0.2:59604->10.2.0.1:5351: recvfrom: connection refused
and any further call to /v1/portforward returns {"port":0} instead of returning the forwarded port. I don't know if my config wrong or if it is a bug. Notably, Gluetun stays healthy and the future logs seem to imply that everything is in order and that it keeps writing the port like nothing happened.

The logs below seem to capture the moment where my other app (that frequently polls the forwarded port) breaks because it doesn't receive a valid port. Note that once Gluetun is in this state, it returns the following:

root@896983587fdc:/# curl --silent -L --fail -H X-API-Key:REDACTED http://localhost:8000/v1/portforward
{"port":0}

EDIT:
I tried to inspect the healtcheck endpoint when this problem occurs. The healtcheck says that everything is fine:

/ # curl --silent -L --fail -H X-API-Key:401xEKPCD08XFOmz80TZFxPZVrAn74P/6spUDjMP5z1eS48JP4KBzg8wgDAGq4kz/zc= http://localhost:8000/v1/portforward
{"port":0}
/ # curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:9999/
200

Share your logs (at least 10 lines)

2026-03-03T14:14:44+01:00 DEBUG [port forwarding] port forwarded 60960 maintained
2026-03-03T14:15:29+01:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-03-03T14:15:30+01:00 DEBUG [port forwarding] port forwarded 60960 maintained
2026-03-03T14:16:15+01:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-03-03T14:16:15+01:00 DEBUG [port forwarding] port forwarded 60960 maintained
2026-03-03T14:16:39+01:00 DEBUG [http server] access to route GET /v1/portforward authorized for role t-anc/GSP-Qbittorent-Gluetun-sync-port-mod
2026-03-03T14:16:39+01:00 INFO [http server] 200 GET /v1/portforward wrote 15B to [::1]:52462 in 54.046µs
2026-03-03T14:17:00+01:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-03-03T14:17:00+01:00 INFO [firewall] removing allowed port 60960...
2026-03-03T14:17:00+01:00 DEBUG [firewall] /usr/sbin/iptables -t filter -L INPUT --line-numbers -n -v
2026-03-03T14:17:00+01:00 DEBUG [firewall] found iptables chain rule matching "--delete INPUT -i tun0 -p tcp -m tcp --dport 60960 -j ACCEPT" at line number 4
2026-03-03T14:17:00+01:00 DEBUG [firewall] /usr/sbin/iptables -t filter -D INPUT 4
2026-03-03T14:17:00+01:00 DEBUG [firewall] /usr/sbin/ip6tables -t filter -L INPUT --line-numbers -n -v
2026-03-03T14:17:00+01:00 DEBUG [firewall] found iptables chain rule matching "--delete INPUT -i tun0 -p tcp -m tcp --dport 60960 -j ACCEPT" at line number 3
2026-03-03T14:17:00+01:00 DEBUG [firewall] /usr/sbin/ip6tables -t filter -D INPUT 3
2026-03-03T14:17:00+01:00 DEBUG [firewall] /usr/sbin/iptables -t filter -L INPUT --line-numbers -n -v
2026-03-03T14:17:00+01:00 DEBUG [firewall] found iptables chain rule matching "--delete INPUT -i tun0 -p udp -m udp --dport 60960 -j ACCEPT" at line number 4
2026-03-03T14:17:00+01:00 DEBUG [firewall] /usr/sbin/iptables -t filter -D INPUT 4
2026-03-03T14:17:00+01:00 DEBUG [firewall] /usr/sbin/ip6tables -t filter -L INPUT --line-numbers -n -v
2026-03-03T14:17:00+01:00 DEBUG [firewall] found iptables chain rule matching "--delete INPUT -i tun0 -p udp -m udp --dport 60960 -j ACCEPT" at line number 3
2026-03-03T14:17:00+01:00 DEBUG [firewall] /usr/sbin/ip6tables -t filter -D INPUT 3
2026-03-03T14:17:00+01:00 INFO [port forwarding] clearing port file /tmp/gluetun/forwarded_port
2026-03-03T14:17:00+01:00 ERROR [port forwarding] adding port mapping: executing remote procedure call: reading from udp connection: read udp 10.2.0.2:59604->10.2.0.1:5351: recvfrom: connection refused
2026-03-03T14:17:00+01:00 INFO [port forwarding] starting
2026-03-03T14:18:39+01:00 DEBUG [http server] access to route GET /v1/portforward authorized for role t-anc/GSP-Qbittorent-Gluetun-sync-port-mod
2026-03-03T14:18:39+01:00 INFO [http server] 200 GET /v1/portforward wrote 11B to [::1]:56742 in 129.038µs
2026-03-03T14:18:49+01:00 DEBUG [http server] access to route GET /v1/portforward authorized for role t-anc/GSP-Qbittorent-Gluetun-sync-port-mod
2026-03-03T14:18:49+01:00 INFO [http server] 200 GET /v1/portforward wrote 11B to [::1]:51632 in 41.609µs
2026-03-03T14:18:59+01:00 DEBUG [http server] access to route GET /v1/portforward authorized for role t-anc/GSP-Qbittorent-Gluetun-sync-port-mod
2026-03-03T14:18:59+01:00 INFO [http server] 200 GET /v1/portforward wrote 11B to [::1]:37266 in 95.394µs
2026-03-03T14:19:09+01:00 DEBUG [http server] access to route GET /v1/portforward authorized for role t-anc/GSP-Qbittorent-Gluetun-sync-port-mod

Share your configuration

gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    restart: always
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - "8888:8888/tcp" # Gluetun Local Network HTTP proxy
      - "8388:8388/tcp" # Gluetun Local Network Shadowsocks
      - "8388:8388/udp" # Gluetun Local Network Shadowsocks
      - "8000:8000/tcp"

      - ${WEBUI_PORT_QBITTORRENT:?err}:${WEBUI_PORT_QBITTORRENT:?err}
    volumes:
      - ${FOLDER_FOR_CONFIGS:?err}/gluetun:/gluetun
    environment:
      PUID: ${PUID:?err}
      PGID: ${PGID:?err}
      TZ: ${TIMEZONE:?err}
      LOG_LEVEL: debug

      VPN_SERVICE_PROVIDER: protonvpn
      VPN_TYPE: wireguard
      WIREGUARD_PRIVATE_KEY_SECRETFILE: /run/secrets/wireguard_private_key

      FIREWALL_OUTBOUND_SUBNETS: 192.168.1.0/24
      SERVER_CITIES: Amsterdam

      # Use this for proton vpn
      SERVER_COUNTRIES: Netherlands
      VPN_PORT_FORWARDING: on
      VPN_PORT_FORWARDING_PROVIDER: protonvpn
      PORT_FORWARD_ONLY: on

    secrets:
      - wireguard_private_key

[github-actions]

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

• do not ask for updates, be patient
• 👍 the issue to show your support instead of commenting
  @qdm12 usually checks issues at least once a week, if this is a new urgent bug,
  revert to an older tagged container image

[mjnewton]

(My setup: Gluetun v3.41.1 built on 2026-02-11T14:22:29.184Z (commit 7f22fb3), also with ProtonVPN/Wireguard)

I seemingly had the same thing occur this morning and I only discovered it when I spotted qBittorrent sitting there listening on port 0 and with no connections as a result. I didn't do any further digging and just opted to restart the container to get everything going again.

I've still got access to my old logs but it looks (to me at least) that you've already posted everything/more that I would've done, but happy to contribute further if anything else is required that might be helpful.

[Flip7413]

I noticed that the issue doesn't happen with Switzerland or France. So it may only concern a few countries like the Netherlands.

[mjnewton]

In my case it was actually Switzerland...

[BenGels]

I’ve the same thing for Netherlands.
I’ll try to Switch to another Country.

[jaimbo]

I also see the same thing intermittently. Gluetun will send my PORT_DOWN command then seemingly fail to get a new port at which point I have to restart the tunnel

2026-03-12T11:26:55Z INFO [firewall] removing allowed port 59485...
2026-03-12T11:26:55Z INFO [port forwarding] clearing port file /tmp/gluetun/forwarded_port
2026-03-12T11:26:55Z ERROR [port forwarding] adding port mapping: executing remote procedure call: reading from udp connection: read udp 10.2.0.2:41201->10.2.0.1:5351: recvfrom: connection refused
2026-03-12T11:26:55Z INFO [port forwarding] starting

I've since spun up a container that watches for this happening and restarts gluetun after 5 minutes of no port being available

[mjnewton]

I've since spun up a container that watches for this happening and restarts gluetun after 5 minutes of no port being available

That's a good idea. Inspired by it I've added the following to a crontab to check every 5 minutes that there's a port being forwarded and restart the app stack if there isn't:

*/5 * * * * if [ "`docker exec gluetun cat /tmp/gluetun/forwarded_port`" = "" ]; then echo "Gluetun no longer forwarding a port! Restarting app stack..."; docker compose -f <pathtoappstack>/compose.yml restart; fi     

It's crude, and perhaps risks catching an otherwise benign situation that would've sorted itself out, but it seems to work as within 30 minutes of me adding it I had the issue arise and it automatically got things back up and running!

[qdm12]

recvfrom: connection refused indicates the protonvpn natpmp server just blocked the connection 🤷
Control server then returns 0 rightfully since there is no forwarded port anymore.
It looks like pf look is restarting, I'll have a look why it stays at 0

[jaimbo]

recvfrom: connection refused indicates the protonvpn natpmp server just blocked the connection 🤷 Control server then returns 0 rightfully since there is no forwarded port anymore. It looks like pf look is restarting, I'll have a look why it stays at 0

It's very intemittent. I've had it happen multiple times per day on occasion and at other times, perhaps only once over a week.

Regular enough that it drove me to vibe a monitoring solution to notify and fix when it happens :(

[mjnewton]

For what it's worth I haven't seen this issue for 9 days now (last occurrence 14th March) despite it previously happening pretty much daily.

How about others?