Bug: Port forwarding sets and maintains firewalled port

[BingoRox]

Is this urgent?

Yes

Host OS

Synology DSM 7.3.2

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-05-21T18:39:34.738Z (commit 1a25f73) on Linux 4.4.302+ (x86_64)

What's the problem 🤔

Port forwarding is setting and maintaining a port that is firewalled. The port is changed, as you can see in the logs, but the new port is not open:

This behaviour was also occurring on the v3.41.1 tag, so I think this is Proton related, (edit: but I will say today I was only able to get a working port on v3.41.1 and it could have been an unrelated issue when I experienced this on the tagged version last week). I initially did not have the updater enable, so I added my credentials for the paid server info, but the issue persists. The only thing that has worked is recreating the container multiple times until a working port is set.

I found that putting {"ports": []} to the control server also resulted in weird behaviour where the port was maintained even though the port file was cleared:

2026-05-22T21:56:17-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-22T21:56:17-04:00 DEBUG [port forwarding] port forwarded 53633 maintained
2026-05-22T21:56:26-04:00 DEBUG [http server] access to route PUT /v1/portforward authorized for role qbittorrent
2026-05-22T21:56:26-04:00 INFO [port forwarding] --2026-05-22 21:56:26--  http://127.0.0.1:8090/api/v2/app/setPreferences
2026-05-22T21:56:26-04:00 INFO [port forwarding] Connecting to 127.0.0.1:8090... connected.
2026-05-22T21:56:27-04:00 INFO [port forwarding] HTTP request sent, awaiting response... 200 OK
2026-05-22T21:56:27-04:00 INFO [port forwarding] Length: 0 [text/plain]
2026-05-22T21:56:27-04:00 INFO [port forwarding] Saving to: 'STDOUT'
2026-05-22T21:56:27-04:00 INFO [port forwarding]      0K                                                        0.00 =0s
2026-05-22T21:56:27-04:00 INFO [port forwarding] 
2026-05-22T21:56:27-04:00 INFO [port forwarding] 2026-05-22 21:56:27 (0.00 B/s) - written to stdout [0/0]
2026-05-22T21:56:27-04:00 INFO [firewall] removing allowed port 53633...
2026-05-22T21:56:27-04:00 INFO [port forwarding] clearing port file /tmp/gluetun/forwarded_port
2026-05-22T21:56:27-04:00 INFO [port forwarding] no port forwarded
2026/05/22 21:56:27 http: panic serving 172.20.0.1:49534: runtime error: index out of range [0] with length 0
goroutine 543 [running]:
net/http.(*conn).serve.func1()
2026-05-22T21:57:02-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-22T21:57:02-04:00 DEBUG [port forwarding] port forwarded 53633 maintained

I have tried other servers with the same result. I don't think the iptables warning is related, since eventually it works with the same warning and the iptables in the container are working correctly based on my limited testing. Let me know what else I can try!

Share your logs (at least 10 lines)

2026-05-22T21:18:18-04:00 INFO [vpn] You are running 1 commit behind the most recent latest
2026-05-22T21:18:18-04:00 INFO [port forwarding] starting
2026-05-22T21:18:18-04:00 DEBUG [port forwarding] gateway external IPv4 address is 185.98.171.161
2026-05-22T21:18:18-04:00 INFO [port forwarding] port forwarded is 38889 (internal port 56789)
2026-05-22T21:18:18-04:00 INFO [firewall] setting allowed input port 56789 through interface tun0...
2026-05-22T21:18:18-04:00 WARN [iptables] IPv6 port redirection disabled because your kernel does not support IPv6 NAT: command failed: "ip6tables-legacy -t nat --append PREROUTING -i tun0 -p tcp --dport 56789 -j REDIRECT --to-ports 38889": ip6tables v1.8.11 (legacy): can't initialize ip6tables table `nat': Table does not exist (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.: exit status 3
2026-05-22T21:18:18-04:00 INFO [port forwarding] writing port file /tmp/gluetun/forwarded_port
2026-05-22T21:18:18-04:00 INFO [port forwarding] --2026-05-22 21:18:18--  http://127.0.0.1:8090/api/v2/app/setPreferences
2026-05-22T21:18:18-04:00 INFO [port forwarding] Connecting to 127.0.0.1:8090... connected.
2026-05-22T21:18:20-04:00 INFO [port forwarding] HTTP request sent, awaiting response... 200 OK
2026-05-22T21:18:20-04:00 INFO [port forwarding] Length: 0 [text/plain]
2026-05-22T21:18:20-04:00 INFO [port forwarding] Saving to: 'STDOUT'
2026-05-22T21:18:20-04:00 INFO [port forwarding] 
2026-05-22T21:18:20-04:00 INFO [port forwarding] 2026-05-22 21:18:20 (0.00 B/s) - written to stdout [0/0]
2026-05-22T21:18:46-04:00 WARN [dns] getting tls connection for request IN A github.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:60792->1.1.1.1:853: read: connection reset by peer
2026-05-22T21:18:46-04:00 WARN [dns] getting tls connection for request IN A tracker.tleechreload.org.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:60786->1.1.1.1:853: read: connection reset by peer
2026-05-22T21:18:46-04:00 WARN [dns] getting tls connection for request IN AAAA tracker.tleechreload.org.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:60784->1.1.1.1:853: read: connection reset by peer
...
more dns warnings
...
2026-05-22T21:18:47-04:00 WARN [dns] getting tls connection for request IN A api.ipify.org.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:60806->1.1.1.1:853: read: connection reset by peer
2026-05-22T21:19:05-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-22T21:19:05-04:00 INFO [port forwarding] --2026-05-22 21:19:05--  http://127.0.0.1:8090/api/v2/app/setPreferences
2026-05-22T21:19:05-04:00 INFO [port forwarding] Connecting to 127.0.0.1:8090... connected.
2026-05-22T21:19:05-04:00 INFO [port forwarding] HTTP request sent, awaiting response... 200 OK
2026-05-22T21:19:05-04:00 INFO [port forwarding] Length: 0 [text/plain]
2026-05-22T21:19:05-04:00 INFO [port forwarding] Saving to: 'STDOUT'
2026-05-22T21:19:05-04:00 INFO [port forwarding] 
2026-05-22T21:19:05-04:00 INFO [port forwarding]      0K                                                        0.00 =0s
2026-05-22T21:19:05-04:00 INFO [port forwarding] 
2026-05-22T21:19:05-04:00 INFO [port forwarding] 2026-05-22 21:19:05 (0.00 B/s) - written to stdout [0/0]
2026-05-22T21:19:05-04:00 INFO [port forwarding] 
2026-05-22T21:19:05-04:00 INFO [firewall] removing allowed port 38889...
2026-05-22T21:19:05-04:00 INFO [port forwarding] clearing port file /tmp/gluetun/forwarded_port
2026-05-22T21:19:05-04:00 ERROR [port forwarding] external port changed from 38889 to 53633
2026-05-22T21:19:05-04:00 INFO [port forwarding] starting
2026-05-22T21:19:05-04:00 DEBUG [port forwarding] gateway external IPv4 address is 185.98.171.161
2026-05-22T21:19:05-04:00 INFO [port forwarding] port forwarded is 53633 (internal port 56789)
2026-05-22T21:19:05-04:00 WARN [iptables] IPv6 port redirection disabled because your kernel does not support IPv6 NAT: command failed: "ip6tables-legacy -t nat --append PREROUTING -i tun0 -p tcp --dport 56789 -j REDIRECT --to-ports 53633": ip6tables v1.8.11 (legacy): can't initialize ip6tables table `nat': Table does not exist (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.: exit status 3
2026-05-22T21:19:05-04:00 INFO [port forwarding] writing port file /tmp/gluetun/forwarded_port
2026-05-22T21:19:05-04:00 INFO [port forwarding] --2026-05-22 21:19:05--  http://127.0.0.1:8090/api/v2/app/setPreferences
2026-05-22T21:19:05-04:00 INFO [port forwarding] Connecting to 127.0.0.1:8090... connected.
2026-05-22T21:19:05-04:00 INFO [port forwarding] HTTP request sent, awaiting response... 200 OK
2026-05-22T21:19:05-04:00 INFO [port forwarding] Length: 0 [text/plain]
2026-05-22T21:19:05-04:00 INFO [port forwarding] Saving to: 'STDOUT'
2026-05-22T21:19:50-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-22T21:19:50-04:00 DEBUG [port forwarding] port forwarded 53633 maintained
2026-05-22T21:20:35-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-22T21:20:35-04:00 DEBUG [port forwarding] port forwarded 53633 maintained
2026-05-22T21:21:20-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-22T21:21:20-04:00 DEBUG [port forwarding] port forwarded 53633 maintained
2026-05-22T21:22:05-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-22T21:22:05-04:00 DEBUG [port forwarding] port forwarded 53633 maintained
... 
port maintained every 45 seconds for at least 20 minutes

Share your configuration

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
      - NET_RAW
    devices:
      - /dev/net/tun:/dev/net/tun
    env_file:
      - .env
    ports:
      - 172.20.0.1:8001:8001          # gluetun control server
      - 172.20.0.1:8888:8888          # HTTP proxy
      - 172.20.0.1:8090:8090          # qbittorrent
    volumes:
      - /volume2/docker/gluetun:/gluetun
      - /volume2/docker/gluetun/auth/config.toml:/gluetun/auth/config.toml
    environment:
      - PUID=$PUID
      - PGID=$PGID
      - TZ=$TZ
      - LOG_LEVEL=debug
      - PUBLICIP_API=ipinfo
      - PUBLICIP_API_TOKEN=$PUBLICIP_API_TOKEN
      - HTTPPROXY=on
      - HTTPPROXY_USER=gluetun
      - HTTPPROXY_PASSWORD=$HTTPPROXY_PASSWORD
      - SHADOWSOCKS=off
      - FIREWALL_OUTBOUND_SUBNETS=172.20.0.0/16,192.168.2.0/24
      - HTTP_CONTROL_SERVER_ADDRESS=:8001
      - BLOCK_MALICIOUS=off
      ### Updater ###
      - UPDATER_PERIOD=24h
      - UPDATER_PROTONVPN_EMAIL=$UPDATER_PROTONVPN_EMAIL
      - UPDATER_PROTONVPN_PASSWORD=$UPDATER_PROTONVPN_PASSWORD
      ### ProtonVPN Config ###
      - VPN_SERVICE_PROVIDER=protonvpn
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=$WIREGUARD_PRIVATE_KEY
      - SERVER_COUNTRIES=$SERVER_COUNTRIES
      - SERVER_CITIES=$SERVER_CITIES
      - SERVER_HOSTNAMES=$SERVER_HOSTNAMES
      - PORT_FORWARD_ONLY=on
      - VPN_PORT_FORWARDING=on
      - WIREGUARD_MTU=1400
      - VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c 'wget -O- --retry-connrefused --post-data "json={\"listen_port\":{{PORTS}}}" http://127.0.0.1:8090/api/v2/app/setPreferences 2>&1'
      - VPN_PORT_FORWARDING_DOWN_COMMAND=/bin/sh -c 'wget -O- --retry-connrefused --post-data "json={\"listen_port\":0" http://127.0.0.1:8090/api/v2/app/setPreferences 2>&1'
    networks:
      - bridge
    restart: always

[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

[qdm12]

I found that putting {"ports": []} to the control server also resulted in weird behaviour where the port was maintained even though the port file was cleared:

Yes that's a bug in that this shouldn't panic. Although what were you trying to achieve, disable Port forwarding?

The only thing that has worked is recreating the container multiple times until a working port is set.

What is the problem though? Have you tried listening with an http server on the publicip:port? I did try with Wireguard + protonvpn and it was working fine using https://github.com/qdm12/port-checker for me

and yes the ipv6 warning can be ignored

[BingoRox]

Although what were you trying to achieve, disable Port forwarding?

I was trying to manually reset the port, but it obviously didn't work haha

The problem is qBittorrent is not connectable over TCP:

You can see in the second image, the first row is the working connection active for 1 day, this was on v3.41.1, then I rebuilt the stack pulling latest and initially the same IP and port were used and still connectable (second row), but on startup the port is changed (third row) and is now unconnectable (this is the logs above), followed by another closed port 38889 as I continued testing. This went on until I reverted to v3.41.1. Like I said, I have also had issues getting a non-working port on v3.41.1 but based on my current testing that may have been a red herring, I think this is more or less isolated to the changes since adding multiple ports for Proton.

I have not tried listening with an http server, but this should just be related to TCP connectivity, I have UDP disabled in qBittorrent. HTTP may be connectable, I can update the issue title to specify TCP if helpful. Happy to test HTTP as well. The image in the first post showing the port being closed was using this tcp/udp port checker for reference: https://www.yougetsignal.com/tools/open-ports/

[qdm12]

Try doing this: #3295 (comment)

To check your forwarded port? This only checks tcp (via http). Note https://www.yougetsignal.com/tools/open-ports/ only works if there is some server listening on that port, so if for example the torrent client isn't listening there it won't work. Better to test manually first to figure out what's wrong. I did test it on my side and it's running fine, but I don't run this configuration long term, so in case it works then doesn't work, debunk what's going on manually and let me know 😉 Thanks!

[qdm12]

I found that putting {"ports": []} to the control server also resulted in weird behaviour where the port was maintained even though the port file was cleared:

Fixed this such that:

1. a1ef736 prevents you from updating ports manually if using the builtin port forwarding code. It makes no sense to update it manually, this was designed for when you have another program handling the port forwarding that was not in gluetun.
2. 46edfe4 sending empty ports does not panic anymore, which can be useful to clear things in the case above

[BingoRox]

@qdm12 Ok I did the test from your comment in #3295, was not successful. Here are the logs:

Gluetun port up:

2026-05-23T10:51:32-04:00 DEBUG [port forwarding] gateway external IPv4 address is 185.98.171.207
2026-05-23T10:51:32-04:00 INFO [port forwarding] port forwarded is 39945 (internal port 56789)
2026-05-23T10:51:32-04:00 INFO [firewall] setting allowed input port 56789 through interface tun0...
...
2026-05-23T10:52:18-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-23T10:52:18-04:00 DEBUG [port forwarding] port forwarded 39945 maintained
2026-05-23T10:53:03-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-23T10:53:03-04:00 DEBUG [port forwarding] port forwarded 39945 maintained
2026-05-23T10:53:48-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-23T10:53:48-04:00 DEBUG [port forwarding] port forwarded 39945 maintained
2026-05-23T10:54:33-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-23T10:54:33-04:00 DEBUG [port forwarding] port forwarded 39945 maintained
2026-05-23T10:55:18-04:00 DEBUG [port forwarding] refreshing forwarded ports since 45 seconds have elapsed
2026-05-23T10:55:18-04:00 DEBUG [port forwarding] port forwarded 39945 maintained

Port checker up:

docker run -it --rm --network="container:gluetun" -e LISTENING_ADDRESS=":39945" qmcgaw/port-checker
...
Running version latest built on 2024-11-19T22:42:54.096Z (commit d6c661d)
...
Settings
├── Listening address: :39945
└── Root URL: /
2026-05-23T10:52:30-04:00 INFO http server listening on [::]:39945

wget times out after a few minutes:

(10:52) docker run -it --rm alpine wget -qO- http://185.98.171.207:39945
(10:55) wget: can't connect to remote host (185.98.171.207): Operation timed out

You can see the port is maintained throughout.

[qdm12]

Use the public ip address not the gateway ip address 185.98.171.207 they're often not the same

[BingoRox]

Use the public ip address not the gateway ip address 185.98.171.207 they're often not the same

It was the same address, just didn't include that log line sorry.

[BingoRox]

Sorry disregard the previous comment, I'm an idiot and forgot to bring down my main instance that uses the same wireguard key lol

As I said in the hidden comment, I set up a testing environment on a different host since Synology's are notorious for strange issues. This host is Running version latest built on 2026-05-23T13:26:51.073Z (commit a1ef736) on Linux 7.0.0-15-generic (x86_64). The port is open as expected connecting to the http server.

So this could be isolated to the Synology kernel. Maybe the new ports setup is not working correctly with iptables-legacy or some other system on the Synology?

Take a look at the iptables for the Ubuntu 26.04 host vs the Synology.

Ubuntu Server 26.04 LTS - Gluetun's forwarded port is 53134 and listed:

docker exec -it gluetun /bin/sh
/ # iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -d 172.22.0.0/16 -i eth0 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 56789 -j ACCEPT
-A INPUT -i tun0 -p udp -m udp --dport 56789 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 53134 -j ACCEPT
-A INPUT -i tun0 -p udp -m udp --dport 53134 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -s 172.22.0.2/32 -d 172.22.0.0/16 -o eth0 -j ACCEPT
-A OUTPUT -s 172.22.0.2/32 -d 172.20.0.0/16 -o eth0 -j ACCEPT
-A OUTPUT -s 172.22.0.2/32 -d 192.168.2.0/24 -o eth0 -j ACCEPT
-A OUTPUT -d 104.254.95.98/32 -o eth0 -p udp -m udp --dport 51820 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

Synology - Gluetun's forwarded port is 63569 but not listed:

docker exec -it gluetun /bin/sh
/ # iptables-legacy -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -d 172.20.0.0/16 -i eth0 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 56789 -j ACCEPT
-A INPUT -i tun0 -p udp -m udp --dport 56789 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -s 172.20.0.3/32 -d 172.20.0.0/16 -o eth0 -j ACCEPT
-A OUTPUT -s 172.20.0.3/32 -d 172.20.0.0/16 -o eth0 -j ACCEPT
-A OUTPUT -s 172.20.0.3/32 -d 192.168.2.0/24 -o eth0 -j ACCEPT
-A OUTPUT -d 185.111.110.65/32 -o eth0 -p udp -m udp --dport 51820 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

[BingoRox]

And here is a working setup on the Synology running v3.41.1 - Gluetun's port forwarding is 34796 and present in the iptables:

docker exec -it gluetun /bin/sh
/ # iptables-legacy -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -d 172.20.0.0/16 -i eth0 -j ACCEPT
-A INPUT -i tun0 -p tcp -m tcp --dport 34796 -j ACCEPT
-A INPUT -i tun0 -p udp -m udp --dport 34796 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -s 172.20.0.27/32 -d 172.20.0.0/16 -o eth0 -j ACCEPT
-A OUTPUT -s 172.20.0.27/32 -d 172.20.0.0/16 -o eth0 -j ACCEPT
-A OUTPUT -s 172.20.0.27/32 -d 192.168.2.0/24 -o eth0 -j ACCEPT
-A OUTPUT -d 185.111.110.66/32 -o eth0 -p udp -m udp --dport 51820 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

[qdm12]

technically on the latest image, the incoming port is 56789, and then it's redirect to the external forwarded port (i.e. 53134), so -A INPUT -i tun0 -p tcp -m tcp --dport 56789 -j ACCEPT should be enough. On the faulty container, what do you get from running iptables-legacy -t nat -nvL PREROUTING?

and what if you run iptables-legacy -A INPUT -i tun0 -p tcp -m tcp --dport 63569 -j ACCEPT, does it fix it then?

[BingoRox]

Ok this is Running version latest built on 2026-05-23T21:51:27.519Z (commit d3e089c) on Linux 4.4.302+ (x86_64) on the Synology, also running the http server as before.

Port:

2026-05-23T19:18:55-04:00 INFO [port forwarding] port forwarded is 37191 (internal port 56789)

Not responsive:

docker run -it --rm alpine wget -qO- http://185.98.171.207:37191
wget: can't connect to remote host (185.98.171.207): Operation timed out

First command:

docker exec -it gluetun /bin/sh
/ # iptables-legacy -t nat -nvL PREROUTING
Chain PREROUTING (policy ACCEPT 568 packets, 34886 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REDIRECT   tcp  --  tun0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:56789 redir ports 37191
    0     0 REDIRECT   udp  --  tun0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:56789 redir ports 37191

After iptables-legacy -A INPUT -i tun0 -p tcp -m tcp --dport 37191 -j ACCEPT it is still unresponsive 😭 (confirmed the routes are added to the iptables, so the command worked, just was unsuccessful)