Update for ProtonVPN update-port.sh

[BigRedBrent]

Disabled exiting on errors to allow the script to keep running even if commands fail, so that it can retry after 45 seconds on the next loop. (I've let the script run for several days, and it looks like this has resolved the issue of it stopping prematurely.)

Returned functionality to allow and deny ports in the firewall as necessary.

Modified the bind_trans function to be less complicated. Removed multiple attempts per loop, because it can retry after 45 seconds on the next loop.

Will now double check to make sure the port has actually changed on the next 45 second loop. This seems to catch incorrect port changes, or at the very least does not switch to a very short lived port change.

Breaking change

<placeholder>

Proposed change

<placeholder>

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New provider (thank you!)
• Updated provider (thank you!)
• New feature (which adds functionality to a provider script/repo usage)
• Breaking change (fix/feature causing existing functionality to break)

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue: relates to #
• Link to documentation updated (if done separately): https://...

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated

[oregonpillow]

@BigRedBrent i tested your script from BigRedBrent:patch-3 and tested manually using latest image and it doesn't work:

2025-12-12 11:05:21 Initialization Sequence Completed
╭───────────────────────────╮
│ ProtonVPN Port Forwarding │
╰───────────────────────────╯
╭──────────────────────────────╮
│ The forwarded port is: 36280 │
╰──────────────────────────────╯
timeout: failed to run command 'ufw': No such file or directory
timeout: failed to run command 'ufw': No such file or directory
Allowing 36280 through the firewall
timeout: failed to run command 'ufw': No such file or directory
Failed while allowing port 36280
timeout: failed to run command 'ufw': No such file or directory
timeout: failed to run command 'ufw': No such file or directory
Allowing 36280 through the firewall
timeout: failed to run command 'ufw': No such file or directory
Failed while allowing port 36280

[BigRedBrent]

@oregonpillow

I was unable to get the firewall to work also, but I was returning the functionality as it was originally there before my first edit that I made, in the hopes that someone will figure out a way to repair it.

The other modifications I made to this commit seem to work pretty well with the firewall disabled. Much better than my first edit did.

[oregonpillow]

ok, well we should try and fix this since breaking ufw (forcing users to have is disabled) is one of the main features of the project. I'll try and take a look maybe tomorrow

[BigRedBrent]

I'm pretty sure it wasn't working before either, so it probably would be a good idea to merge this so that the fix can be done with these changes that are very useful.

I haven't had any issues with the script since I've made these changes, other than the functionality that never originally worked anyway needing to be fixed.

[BigRedBrent]

Also, as long as a kill switch has been set, I see no reason for port blocking. Has a kill switch been enabled in this docker container?

If a kill switch hasn't been added, I used AI to whip this up:

/scripts/transmission-pre-start.sh

#!/bin/bash
#chmod +x /scripts/transmission-pre-start.sh

ENABLE_KILL_SWITCH="true"

set -euo pipefail

init_kill_switch() {
    if ! iptables -L >/dev/null 2>&1; then
        if [[ "$ENABLE_KILL_SWITCH" != "true" ]]; then
            return 0
        fi
        echo -e "$(date '+%Y-%m-%d %T')\tNET_ADMIN is not enabled!"
        return 1
    fi

    echo -e "$(date '+%Y-%m-%d %T')\tFlushing iptables"
    if ! iptables -F || ! iptables -X; then
        echo -e "$(date '+%Y-%m-%d %T')\tERROR: Failed to flush iptables"
        return 1
    fi

    if [[ "$ENABLE_KILL_SWITCH" != "true" ]]; then
        iptables -P INPUT ACCEPT
        iptables -P OUTPUT ACCEPT
        iptables -P FORWARD ACCEPT
        echo -e "$(date '+%Y-%m-%d %T')\tiptables reset to default"
        return 0
    fi

    echo -e "$(date '+%Y-%m-%d %T')\tInitializing VPN kill switch"

    iptables -P INPUT DROP || { echo -e "$(date '+%Y-%m-%d %T')\tERROR: Failed to set INPUT DROP policy"; return 1; }
    iptables -P OUTPUT DROP || { echo -e "$(date '+%Y-%m-%d %T')\tERROR: Failed to set OUTPUT DROP policy"; return 1; }
    iptables -P FORWARD DROP || { echo -e "$(date '+%Y-%m-%d %T')\tERROR: Failed to set FORWARD DROP policy"; return 1; }

    iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT

    vpn_interfaces=$(ip -o link show | awk -F': ' '{print $2}' | grep -E '^(tun|tap|wg|ppp)' || true)
    if [[ -z "$vpn_interfaces" ]]; then
        echo -e "$(date '+%Y-%m-%d %T')\tERROR: No VPN interface found"
        return 1
    fi
    for iface in $vpn_interfaces; do
        iptables -A INPUT -i "$iface" -j ACCEPT
        iptables -A OUTPUT -o "$iface" -j ACCEPT
    done

    if [[ -n "${LOCAL_NETWORK:-}" ]]; then
        iptables -A INPUT -s "${LOCAL_NETWORK}" -j ACCEPT
        iptables -A OUTPUT -d "${LOCAL_NETWORK}" -j ACCEPT
    fi

    iptables -A INPUT -p tcp --dport "${TRANSMISSION_RPC_PORT:-9091}" -j ACCEPT

    echo -e "$(date '+%Y-%m-%d %T')\tVPN kill switch initialized"
}

init_kill_switch

[oregonpillow]

Just as an FYI, I recently switched to gluetun + transmission as an alternative to Haugene. I've been using Haugene for years (4-5?) but have to say that the gluetun stack works much better for me. With proton, the port forwarding works immediately.

If you're not set on Haugene I just want to let you know it exists. But if you need an AIO solution, then Haugene is the way to go.

[BigRedBrent]

@oregonpillow
I may consider going the route of using gluetun + transmission. What specific docker images are you using?

[oregonpillow]

@oregonpillow I may consider going the route of using gluetun + transmission. What specific packages are you using?

not so much packages, but docker images. I'm using lscr.io/linuxserver/transmission:4.0.5 + qmcgaw/gluetun. With the "gluetun setup":

• you tell transmission container to use the same network stack as the gluetun container by setting network_mode: "service:gluetun" on the transmission container
• this means there is no need for iptables to prevent leaks. If gluetun is down, transmission is down
• because transmission uses the gluetun networking stack, this means that the 9091 transmission port for example, is actually now on the gluetun container (because they share the same networking stack)
• this means you expose 9091:9091 on the gluetun container, or in my case, i also add my nginx network to the gluetun container, and my nginx container points to gluetun:9091 (transmission).
  There is some good documentation on it and also some good youtube videos which cover it.

I hope nobody from this project is offended that i post this here, they are just different projects that approach it from different angles. Gluetun is not specific to transmission, you can route any container through it's vpn. For example, many people add their radarr, sonarr stack to it as well.

[BigRedBrent]

I couldn't get gluetun + transmission to work. Perhaps it's because I'm using a custom QNAP network configuration.

[Forage]

The changes seem to be working nicely, thanks.

Two remarks:

1. Why the rather high 60 seconds time-out at the start?
2. Why insist on updating the packages natpmpc and jq if they are already installed? I don't consider it the responsibility of this script.

I had to add "--dns ..." to not have the updating of the already installed packages end with a time-out after a long long wait for both packages and to have it actually open a port. Would this be something we can have the script check beforehand and notify when such a setting appears to be needed? Or would it be better to have this step included even before the update-port script is run?

[BigRedBrent]

@Forage

I updated the script so that it waits for the health check to pass, and no longer updates already installed packages.

[BigRedBrent]

@haugene @pkishino

I've added additional checks to see if packages are available and install them if they are not. This file currently functions better than the current official release of this file. The current release has no additional functionality over this version, and so I suggest merging this version as soon as possible.

[Forage]

Still does the job as it should. Thanks.
FYI: with #3009 applied, the --dns argument is no longer needed either.