Avoids gluetun's ProtonVPN server name lookup entirely. All WireGuard
parameters (endpoint, peer key, client address, keepalive) come directly
from the downloaded ProtonVPN config.
US-TX#179 and US-TX#220 were failing — WireGuard handshake completing
but no traffic passing (silent drop). Switching both workers to US-IL#267
and pinning the endpoint IP and peer public key directly to avoid relying
on gluetun's built-in server list lookup.
Python 3.14 raises PatternError for backslash sequences like \P in
re.sub replacement strings. Switch to lambda replacements which bypass
that interpretation. Also pin to python:3.13-alpine to avoid future
surprises from pulling :3-alpine.
Switch qbt-config-patch from busybox/sed to python:3-alpine so we can
cleanly handle INI keys with backslashes. Now seeds both password hash
and high-throughput defaults (3000 max connections, 50 active downloads,
unlimited rate) on fresh PVC deployments. Existing configs are updated
in-place; API-applied values are preserved on restart.
LocalhostAuthEnabled=false isn't honored in this qBT version. Instead, initContainer
stamps the PBKDF2 hash for admin:adminadmin before startup so all three pods have
consistent credentials. portforward-helper and coordinator restored to cookie-based
SID auth.
Adds qbt-config-patch initContainer that sets WebUI\LocalhostAuthEnabled=false
in qBittorrent.conf before the main containers start. Prevents qBittorrent from
overwriting the setting (previously edited at runtime, lost on pod restart).
LocalhostAuthEnabled=false set in all three qbt configs. portforward-helper and
coordinator now call the API directly without auth — no more ban risk from failed
login attempts.
- portforward-helper now reads /tmp/gluetun/forwarded_port via shared emptyDir
volume instead of polling gluetun HTTP API (which returned Unauthorized)
- Main qbt: SERVER_NAMES=US-IL#1 (valid entry in gluetun server list)
- Both manifests cleaned up
- Main qbt: switch from pinned US-IL#149 (no PF) to SERVER_REGIONS=Illinois so
gluetun picks any IL server with port forwarding enabled
- Fornax workers: portforward-helper 32Mi→96Mi to stop OOMKill
US-TX#253 and US-TX#34 aren't in gluetun's built-in list. Switching to:
- Main qbt: US-IL#149 (was US-IL#267)
- Fornax TX253: US-TX#179
- Fornax TX34: US-TX#220
Private keys are per-account and work with any ProtonVPN WireGuard server.
Replaces DIY natpmpc sidecar with gluetun's built-in NAT-PMP handling for the protonvpn
provider. The natpmpc UDP response was being dropped by gluetun's firewall since conntrack
doesn't track stateless UDP from the gateway. With VPN_PORT_FORWARDING=on, gluetun handles
the NAT-PMP exchange internally and exposes the port at :8000/v1/openvpn/portforwarded.
Helper sidecar now just polls that endpoint.
Two initial Fornax distributed torrent workers, each a gluetun+qBittorrent+natpmpc-helper
pod on a different ProtonVPN TX server with NAT-PMP enabled. VPN private keys stored in
Vault at secret/fornax/worker-tx253 and secret/fornax/worker-tx34, surfaced via
ExternalSecrets. Workers share the media-data PVC; each has its own config PVC.
Services: fornax-worker-tx253:8080 and fornax-worker-tx34:8080 (ClusterIP, media ns)
Will Anderson