Container gives bindPort Error on Startup

[thatMacAdmin]

Is there a pinned issue for this?

• I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• I have searched the existing issues
• I have searched the existing discussions

Is there any comment in the documentation for this?

• I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

• I have checked the provider repo for issues
• My issue is NOT related to a provider

Are you using the latest release?

• I am using the latest release

Have you tried using the dev branch latest?

• I have tried using dev branch

Docker run config used

apiVersion: apps/v1
kind: Deployment
metadata:
name: transmission
namespace: media
spec:
selector:
matchLabels:
app: transmission
replicas: 1
template:
metadata:
labels:
app: transmission
spec:
volumes:
- name: transmission-config
persistentVolumeClaim:
claimName: transmission-config-pvc
- name: transmission-download
persistentVolumeClaim:
claimName: transmission-download-pvc
- name: transmission-media
persistentVolumeClaim:
claimName: pvc-media-nfs
containers:
- name: transmission-server
image: haugene/transmission-openvpn
securityContext:
capabilities:
add: ["NET_ADMIN"]
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9091
- containerPort: 19999
env:
- name: PUID
value: "1000"
- name: PGID
value: "1000"
- name: "CREATE_TUN_DEVICE"
value: "true"
- name: "OPENVPN_PROVIDER"
value: "PIA"
- name: "OPENVPN_CONFIG"
value: "us_chicago"
- name: "LOCAL_NETWORK"
value: "10.42.0.0/16,10.43.0.0/16"
- name: "OPENVPN_USERNAME"
value: "redacted"
- name: "OPENVPN_PASSWORD"
value: "redacted"
- name: "HEALTH_CHECK_HOST"
value: "209.222.18.222"
volumeMounts:
- name: transmission-config
mountPath: /config
- name: transmission-download
mountPath: /data
- name: transmission-media
mountPath: /media

Current Behavior

When the container starts up it is able to setup the VPN connection without issues and moves on to Transmission but then it fails.

Expected Behavior

I expect that the container should start up as expected.

How have you tried to solve the problem?

I have edited multiple configuration options but I am unclear on how to proceed.

Log output

Starting container with revision: 07f5a2b9aea5028c9bb75438c1552708e91dde71
TRANSMISSION_HOME is currently set to: /config/transmission-home
Creating TUN device /dev/net/tun
Using OpenVPN provider: PIA
Running with VPN_CONFIG_SOURCE auto
Provider PIA has a bundled setup script. Defaulting to internal config
Executing setup script for PIA
Downloading OpenVPN config bundle openvpn into temporary file /tmp/tmp.fdcH0DqiaR
Extract OpenVPN config bundle into PIA directory /etc/openvpn/pia
Starting OpenVPN using config us_chicago.ovpn
Modifying /etc/openvpn/pia/us_chicago.ovpn for best behaviour in this container
Modification: Point auth-user-pass option to the username/password file
Modification: Change ca certificate path
Modification: Change ping options
Modification: Update/set resolv-retry to 15 seconds
Modification: Change tls-crypt keyfile path
Modification: Set output verbosity to 3
Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop
Modification: Updating status for config failure detection
Setting OpenVPN credentials...
adding route to local network 10.42.0.0/16 via 10.42.7.1 dev eth0
adding route to local network 10.43.0.0/16 via 10.42.7.1 dev eth0
2024-02-24 19:24:36 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'aes-128-cbc' to --data-ciphers or change --cipher 'aes-128-cbc' to --data-ciphers-fallback 'aes-128-cbc' to silence this warning.
2024-02-24 19:24:36 OpenVPN 2.5.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 29 2023
2024-02-24 19:24:36 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2024-02-24 19:24:36 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-02-24 19:24:36 CRL: loaded 1 CRLs from file -----BEGIN X509 CRL-----
MIICWDCCAUAwDQYJKoZIhvcNAQENBQAwgegxCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTETMBEGA1UEBxMKTG9zQW5nZWxlczEgMB4GA1UEChMXUHJpdmF0ZSBJbnRl
cm5ldCBBY2Nlc3MxIDAeBgNVBAsTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMSAw
HgYDVQQDExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4GA1UEKRMXUHJpdmF0
ZSBJbnRlcm5ldCBBY2Nlc3MxLzAtBgkqhkiG9w0BCQEWIHNlY3VyZUBwcml2YXRl
aW50ZXJuZXRhY2Nlc3MuY29tFw0xNjA3MDgxOTAwNDZaFw0zNjA3MDMxOTAwNDZa
MCYwEQIBARcMMTYwNzA4MTkwMDQ2MBECAQYXDDE2MDcwODE5MDA0NjANBgkqhkiG
9w0BAQ0FAAOCAQEAQZo9X97ci8EcPYu/uK2HB152OZbeZCINmYyluLDOdcSvg6B5
jI+ffKN3laDvczsG6CxmY3jNyc79XVpEYUnq4rT3FfveW1+Ralf+Vf38HdpwB8EW
B4hZlQ205+21CALLvZvR8HcPxC9KEnev1mU46wkTiov0EKc+EdRxkj5yMgv0V2Re
ze7AP+NQ9ykvDScH4eYCsmufNpIjBLhpLE2cuZZXBLcPhuRzVoU3l7A9lvzG9mjA
5YijHJGHNjlWFqyrn1CfYS6koa4TGEPngBoAziWRbDGdhEgJABHrpoaFYaL61zqy
MR6jC0K2ps9qyZAN74LEBedEfK7tBOzWMwr58A==
-----END X509 CRL-----

2024-02-24 19:24:36 TCP/UDP: Preserving recently used remote address: [AF_INET]181.214.166.249:1198
2024-02-24 19:24:36 Socket Buffers: R=[212992->212992] S=[212992->212992]
2024-02-24 19:24:36 UDP link local: (not bound)
2024-02-24 19:24:36 UDP link remote: [AF_INET]181.214.166.249:1198
2024-02-24 19:24:36 TLS: Initial packet from [AF_INET]181.214.166.249:1198, sid=59196eae 7e99849d
2024-02-24 19:24:36 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-02-24 19:24:36 VERIFY OK: depth=1, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, emailAddress=[email protected]
2024-02-24 19:24:36 VERIFY KU OK
2024-02-24 19:24:36 Validating certificate extended key usage
2024-02-24 19:24:36 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-02-24 19:24:36 VERIFY EKU OK
2024-02-24 19:24:36 VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=chicago421, name=chicago421
2024-02-24 19:24:36 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA512
2024-02-24 19:24:36 [chicago421] Peer Connection Initiated with [AF_INET]181.214.166.249:1198
2024-02-24 19:24:36 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.28.112.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.28.112.236 255.255.255.0,peer-id 0,cipher AES-128-GCM'
2024-02-24 19:24:36 OPTIONS IMPORT: timers and/or timeouts modified
2024-02-24 19:24:36 OPTIONS IMPORT: compression parms modified
2024-02-24 19:24:36 OPTIONS IMPORT: --ifconfig/up options modified
2024-02-24 19:24:36 OPTIONS IMPORT: route options modified
2024-02-24 19:24:36 OPTIONS IMPORT: route-related options modified
2024-02-24 19:24:36 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-02-24 19:24:36 OPTIONS IMPORT: peer-id set
2024-02-24 19:24:36 OPTIONS IMPORT: adjusting link_mtu to 1625
2024-02-24 19:24:36 OPTIONS IMPORT: data channel crypto options modified
2024-02-24 19:24:36 Data Channel: using negotiated cipher 'AES-128-GCM'
2024-02-24 19:24:36 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
2024-02-24 19:24:36 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
2024-02-24 19:24:36 net_route_v4_best_gw query: dst 0.0.0.0
2024-02-24 19:24:36 net_route_v4_best_gw result: via 10.42.7.1 dev eth0
2024-02-24 19:24:36 ROUTE_GATEWAY 10.42.7.1/255.255.255.0 IFACE=eth0 HWADDR=fe:74:04:81:6d:d8
2024-02-24 19:24:36 GDG6: remote_host_ipv6=n/a
2024-02-24 19:24:36 net_route_v6_best_gw query: dst ::
2024-02-24 19:24:36 sitnl_send: rtnl: generic error (-101): Network is unreachable
2024-02-24 19:24:36 ROUTE6: default_gateway=UNDEF
2024-02-24 19:24:36 TUN/TAP device tun0 opened
2024-02-24 19:24:36 net_iface_mtu_set: mtu 1500 for tun0
2024-02-24 19:24:36 net_iface_up: set tun0 up
2024-02-24 19:24:36 net_addr_v4_add: 10.28.112.236/24 dev tun0
2024-02-24 19:24:36 net_route_v4_add: 181.214.166.249/32 via 10.42.7.1 dev [NULL] table 0 metric -1
2024-02-24 19:24:36 net_route_v4_add: 0.0.0.0/1 via 10.28.112.1 dev [NULL] table 0 metric -1
2024-02-24 19:24:36 net_route_v4_add: 128.0.0.0/1 via 10.28.112.1 dev [NULL] table 0 metric -1
2024-02-24 19:24:36 WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tun0, therefore the route installation may fail or may not work as expected.
2024-02-24 19:24:36 add_route_ipv6(2000::/3 -> :: metric -1) dev tun0
2024-02-24 19:24:36 net_route_v6_add: 2000::/3 via :: dev tun0 table 0 metric -1
Up script executed with device=tun0 ifconfig_local=10.28.112.236
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.28.112.236
Enforcing ownership on transmission directories
Applying permissions to transmission directories
Setting owner for transmission paths to 1000:1000
Setting permissions for download and incomplete directories
umask: 2
Directories: 775
Files: 664
Setting permission for watch directory (775) and its files (664)

---

Transmission will run as

User name: abc
User uid: 1000
User gid: 1000

Updating Transmission settings.json with values from env variables
Attempting to use existing settings.json for Transmission
Successfully used existing settings.json /config/transmission-home/settings.json
Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 10.28.112.236
Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /data/completed
Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /data/incomplete
Overriding rpc-password because TRANSMISSION_RPC_PASSWORD is set to [REDACTED]
Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091
Overriding rpc-username because TRANSMISSION_RPC_USERNAME is set to
Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch
sed'ing True to true
STARTING TRANSMISSION
Provider PIA has a script for automatic port forwarding. Will run it now.
If you want to disable this, set environment variable DISABLE_PORT_UPDATER=true
Transmission startup script complete.
2024-02-24 19:24:37 Initialization Sequence Completed
Running functions for token based port fowarding
curl: (7) Failed to connect to 10.28.112.1 port 19999 after 21 ms: Connection refused
Sat Feb 24 19:24:43 UTC 2024: getSignature error

the has been a fatal_error
curl: (7) Failed to connect to 10.28.112.1 port 19999 after 20 ms: Connection refused
Sat Feb 24 19:24:43 UTC 2024: bindPort error

the has been a fatal_error
transmission auth not required
waiting for transmission to become responsive
transmission became responsive
ID Done Have ETA Up Down Ratio Status Name
Sum: None 0.0 0.0
setting transmission port to
localhost:9091/transmission/rpc/ responded: success
Checking port...
Error: Couldn't test port: Bad Request (400)
#######################
SUCCESS
#######################
Port:
Expiration Sat Feb 24 00:00:00 UTC 2024
#######################
Entering infinite while loop
Every 15 minutes, check port status
60 day port reservation reached
Getting a new one
curl: (7) Failed to connect to 10.28.112.1 port 19999 after 21 ms: Connection refused
Sat Feb 24 19:24:55 UTC 2024: getSignature error

the has been a fatal_error
curl: (7) Failed to connect to 10.28.112.1 port 19999 after 21 ms: Connection refused
Sat Feb 24 19:24:56 UTC 2024: bindPort error

the has been a fatal_error
transmission auth not required
waiting for transmission to become responsive
transmission became responsive
ID Done Have ETA Up Down Ratio Status Name
Sum: None 0.0 0.0
setting transmission port to
localhost:9091/transmission/rpc/ responded: success
Checking port...
Error: Couldn't test port: Bad Request (400)

HW/SW Environment

- Kubernetes

Anything else?

No response

[pkishino]

This is provider script PIA related..
Please check different server , there were sine updates to PIA recently I think

[joe-eklund]

Hey I just started getting similar errors to you and found that changing my dns from google to cloudflare resolved my issue.

    dns:
      #- 8.8.8.8
      #- 8.8.4.4
      - 1.1.1.1
      - 1.0.0.1

If you were using google as your dns, maybe give that a shot?

Edit: I think this issue came back again for me, so I'm not totally sure why it's happening. It seemed sudden after me not changing anything for many months, so probably some issue with PIA maybe.

@pkishino

This is provider script PIA related..
Please check different server , there were sine updates to PIA recently I think

What updates are you referring to? I don't see any recent updates for PIA in this repo.

[joe-eklund]

As a followup to my last comment, this seemed to be an issues with PIA. The issue disappeared after a few hours and has been good for a couple days now.