Bug: The ProtonVPN port is changing every minute

[brumik]

EDIT

This seems to be working fine if I switch to OpenVPN TCP. So I am guessing that this is some issue with dropped UDP packages on Wireguard. (I havent tested OpenVPN UDP)

Is this urgent?

No

Host OS

NixOS

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 2025-12-29T05:33:29.822Z (commit 9b9b723)

What's the problem 🤔

Everything works but every second check for port on protonvpn returns an error and changed port. It updates as expected but it seems the port changes just about every 50s-1m that means that connection for apps that depend on open port is broken.

I cannot pinpoint it to a exact point, but I noticed issues first about at least 3 weeks ago (sorry, tooke me a bit to get into investigation)

Share your logs (at least 10 lines)

Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z ERROR [port forwarding] external port changed: 59264 changed to 45666
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z INFO [port forwarding] starting
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z INFO [port forwarding] gateway external IPv4 address is 45.92.33.174
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z INFO [port forwarding] port forwarded is 45666
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z INFO [firewall] setting allowed input port 45666 through interface tun0...
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z DEBUG [firewall] /usr/sbin/iptables --append INPUT -i tun0 -p tcp -m tcp --dport 45666 -j ACCEPT
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z DEBUG [firewall] /usr/sbin/ip6tables --append INPUT -i tun0 -p tcp -m tcp --dport 45666 -j ACCEPT
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z DEBUG [firewall] /usr/sbin/iptables --append INPUT -i tun0 -p udp -m udp --dport 45666 -j ACCEPT
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z DEBUG [firewall] /usr/sbin/ip6tables --append INPUT -i tun0 -p udp -m udp --dport 45666 -j ACCEPT
Mär 05 21:31:21 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:21Z INFO [port forwarding] writing port file /tmp/gluetun/forwarded_port
Mär 05 21:31:22 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:22Z DEBUG [dns] response blocked for ipv4.tracker.harry.lu. because 127.0.0.1 is private and the question name is not local nor exempt from rebinding protection
Mär 05 21:31:34 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:34Z DEBUG [dns] exchanging over tls connection (2000ms) for request IN A thinking.duckdns.org.: read tcp 10.2.0.2:57982->1.1.1.1:853: i/o timeout
Mär 05 21:31:37 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:37Z DEBUG [dns] response blocked for opentracker.internetwarriors.net. because 127.0.0.1 is private and the question name is not local nor exempt from rebinding protection
Mär 05 21:31:48 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:48Z DEBUG [dns] response blocked for ipv4.tracker.harry.lu. because 127.0.0.1 is private and the question name is not local nor exempt from rebinding protection
Mär 05 21:31:50 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:50Z DEBUG [http server] access to route GET /v1/portforward authorized for role nicotine
Mär 05 21:31:50 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:31:50Z INFO [http server] 200 GET /v1/portforward wrote 15B to 127.0.0.1:32990 in 33.419µs
Mär 05 21:32:06 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:06Z DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
Mär 05 21:32:06 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:06Z DEBUG [port forwarding] port forwarded 45666 maintained
Mär 05 21:32:50 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:50Z DEBUG [http server] access to route GET /v1/portforward authorized for role nicotine
Mär 05 21:32:50 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:50Z INFO [http server] 200 GET /v1/portforward wrote 15B to 127.0.0.1:45136 in 38.946µs
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z INFO [firewall] removing allowed port 45666...
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/iptables -t filter -L INPUT --line-numbers -n -v
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] found iptables chain rule matching "--delete INPUT -i tun0 -p tcp -m tcp --dport 45666 -j ACCEPT" at line number 4
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/iptables -t filter -D INPUT 4
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/ip6tables -t filter -L INPUT --line-numbers -n -v
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] found iptables chain rule matching "--delete INPUT -i tun0 -p tcp -m tcp --dport 45666 -j ACCEPT" at line number 3
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/ip6tables -t filter -D INPUT 3
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/iptables -t filter -L INPUT --line-numbers -n -v
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] found iptables chain rule matching "--delete INPUT -i tun0 -p udp -m udp --dport 45666 -j ACCEPT" at line number 4
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/iptables -t filter -D INPUT 4
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/ip6tables -t filter -L INPUT --line-numbers -n -v
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] found iptables chain rule matching "--delete INPUT -i tun0 -p udp -m udp --dport 45666 -j ACCEPT" at line number 3
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/ip6tables -t filter -D INPUT 3
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z INFO [port forwarding] clearing port file /tmp/gluetun/forwarded_port
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z ERROR [port forwarding] external port changed: 45666 changed to 60293
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z INFO [port forwarding] starting
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z INFO [port forwarding] gateway external IPv4 address is 45.92.33.174
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z INFO [port forwarding] port forwarded is 60293
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z INFO [firewall] setting allowed input port 60293 through interface tun0...
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/iptables --append INPUT -i tun0 -p tcp -m tcp --dport 60293 -j ACCEPT
Mär 05 21:32:51 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:51Z DEBUG [firewall] /usr/sbin/ip6tables --append INPUT -i tun0 -p tcp -m tcp --dport 60293 -j ACCEPT
Mär 05 21:32:52 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:52Z DEBUG [firewall] /usr/sbin/iptables --append INPUT -i tun0 -p udp -m udp --dport 60293 -j ACCEPT
Mär 05 21:32:52 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:52Z DEBUG [firewall] /usr/sbin/ip6tables --append INPUT -i tun0 -p udp -m udp --dport 60293 -j ACCEPT
Mär 05 21:32:52 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:32:52Z INFO [port forwarding] writing port file /tmp/gluetun/forwarded_port
Mär 05 21:33:37 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:33:37Z DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
Mär 05 21:33:37 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:33:37Z DEBUG [port forwarding] port forwarded 60293 maintained
Mär 05 21:33:50 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:33:50Z DEBUG [http server] access to route GET /v1/portforward authorized for role nicotine
Mär 05 21:33:50 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:33:50Z INFO [http server] 200 GET /v1/portforward wrote 15B to 127.0.0.1:45954 in 49.832µs
Mär 05 21:33:55 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:33:55Z DEBUG [dns] renewing tls connection for request IN A dht.transmissionbt.com.: dialing tcp 1.1.1.1:853: dial tcp 1.1.1.1:853: i/o timeout
Mär 05 21:34:00 sleeper docker-gluetun-transmission-start[2275066]: 2026-03-05T20:34:00Z DEBUG [dns] renewing tls connection for request IN A dht.transmissionbt.com.: dialing tcp 1.0.0.1:853: dial tcp 1.0.0.1:853: i/o timeout

Share your configuration

# + a secret as env file for wireguard
      gluetun-transmission = {
        image = "qmcgaw/gluetun:latest";
        # pull = "always";
        ports = [
          # For transmission since the networking is going through this container
          "9092:9091"
          "51413:51413"
          "51413:51413/udp"
        ];
        capabilities = { NET_ADMIN = true; };
        environment = {
          LOG_LEVEL = "debug";
          VPN_SERVICE_PROVIDER = "protonvpn";
          VPN_TYPE = "wireguard";
          SERVER_COUNTRIES = "Greece";
          PORT_FORWARD_ONLY = "on";
          VPN_PORT_FORWARDING = "on";
          GLUETUN_HTTP_CONTROL_SERVER_ENABLE = "on";
          HTTP_CONTROL_SERVER_AUTH_CONFIG_FILEPATH = "/gluetun/auth/config.toml";
        };
        volumes = [
          "${cfg.baseDir}/gluetun-auth-config.toml:/gluetun/auth/config.toml"
        ];
        environmentFiles = [ config.sops.templates."n100/gluetun/.env".path ];
        devices = [ "/dev/net/tun:/dev/net/tun" ];

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

It actually maintains it on the second try

port forwarded 45666 maintained

But does change on the 3rd try. I don't think it's related to connection reliability, because you get that new port assigned (and this natpmp protocol runs over tcp, rpc). Maybe it's a bugged wireguard server natpmp component, have you tried other wireguard servers?

Also, your connected container should be able to continue working on a forwarded port change with VPN_PORT_FORWARDING_UP_COMMAND and down command, see the wiki. For transmission there is also #2611 which will get merged soon.

Ps: GLUETUN_HTTP_CONTROL_SERVER_ENABLE doesn't exist, most likely AI Hallucination

[astarte75]

Adding PORT_FORWARDING_ONLY=yes to the gluetun environment resolved the issue immediately. The port has been stable ever since with zero changes.

environment:

• VPN_PORT_FORWARDING=on
• PORT_FORWARDING_ONLY=yes

Note: VPN_PORT_FORWARDING=on alone was not sufficient — the PORT_FORWARDING_ONLY=yes option is what forces gluetun to connect exclusively to ProtonVPN servers with a working port forwarding implementation, avoiding the ones with the buggy NAT-PMP component.

Environment

• gluetun latest (built 2026-03-05, commit bd275aa)
• ProtonVPN WireGuard, Switzerland/Zurich
• VPN_PORT_FORWARDING=on was already set before the fix

[yarafie]

Sorry to intrude here, just a basic question, when you created this specific wireguard key for proton, did you select the port forward option?

[astarte75]

I thought I had found the problem, but actually it doesn't work that way either. After restarting, the stack continues with the same port change every minute or so.

[violetviolinist]

I had the exact same issue. I generated a new WireGuard config on my Proton account and that solved it. Also, make sure you don't enable the "Moderate NAT" feature when doing so. Proton says it is incompatible with NAT-PMP (even though it allows you to create a config with both enabled).

Edit: I just realized, I was running two different gluetun containers with the same Wireguard private key. It's possible (and most likely) that the two were interfering with each other's NAT-PMP renewals. I used the new Wireguard key on one of the containers, and now both are working.

[qdm12]

I'm looking forward to a discovery, but I don't think it has anything to do with gluetun; especially if it works fine sometimes and sometimes it doesn't, i would say either protonvpn sucks again or user error? You can always try running VPN_PORT_FORWARDING=off and run natpmpc inside gluetun, but I don't think that will solve much.

[astarte75]

Thank you @violetviolinist . Regenerating the WireGuard key on ProtonVPN fixed it. The port has been stable ever since.

[brumik]

Hey, sorry took me a bit to get back here.

GLUETUN_HTTP_CONTROL_SERVER_ENABLE I think you are right, though I do not let AI touch my homelab code, I might have got it from there.

So from previous answers, I do run multiple standalone gluetun containers, but I was getting this when I was running one too. I will try to regenerate the key. However to my understanding (from docs) you can reuse the key, and a key shoul work with any servers. I had this working before as I said for a year or so now, but it very well might be something with proton (or my network). Networking issues are hard to debug :/.

Thanks for the time, and the comments, if I pinpoint it down I'll let you know. For the time being I think you can close the issue, as for others it seems to work and for me it is non blocking.

[DarkVader-cell]

I have been running into this for a while now, not able to pinpoint the specific commit. Similar setup as above, same WG key for multiple instances of gluetun.

I can also confirm that switching to OpenVPN fixed the issue, gave me a stable port for days, but the speed took a heavy hit (almost 30x less). Maybe as @violetviolinist mentioned I'll test out different keys for different instances

UPDATE: Disabling Moderate NAT and using an unique key per instance seems to be stable as of now.

[emre1393]

i had similar port issue, using unique wireguard key for each instance fixed the issue for me.