fix(vpn): PIA OpenVPN on UDP/53 (avoid home WAN:1197 conflict); re-enable vpn-egress

Operator identified the block: the home network NATs its own OpenVPN server on
WAN:1197, colliding with the cluster's outbound PIA-on-1197 flow (port-specific,
not a general UDP block — UDP/53 worked in tcpdump). PIA accepts OpenVPN on
53/1194/1197/1198/8080/9201; chose 53 (empirically proven to traverse this net).

- cluster-vars: add PIA_OPENVPN_PORT="53"
- gluetun: OPENVPN_ENDPOINT_PORT=${PIA_OPENVPN_PORT}
- re-enable vpn-egress; DECISIONS-LOG resolution noted

Co-Authored-By: Claude Opus 4.8 <[email protected]>

DECISIONS-LOG.md

@@ -507,3 +507,13 @@ filtering; try a wired connection to the main 192.168.1.x LAN; or a different po
 workaround — the user requires non-TCP, and WireGuard (the fallback) is also UDP so likely blocked the same
 way. `vpn-egress` reverted to disabled meanwhile (config is complete + correct; one-line re-enable once the
 network passes OpenVPN UDP).
+
+### Phase 3 VPN — RESOLVED: it was a port-1197 collision, moved to UDP/53 (2026-08-22)
+Operator clarified: the home network already runs **its own OpenVPN server NAT'd on WAN:1197**, which
+collided with the cluster's outbound PIA-on-1197 flow at the router (why UDP/53 worked but 1197 didn't —
+port-specific, not a general UDP block). Fix: set `OPENVPN_ENDPOINT_PORT` to a non-1197 PIA OpenVPN port.
+PIA accepts `53, 1194, 1197, 1198, 8080, 9201` (gluetun issue #2252). Chose **53** — empirically proven to
+traverse this network (the `dig @9.9.9.9` test) and no conflict. Added cluster-var `PIA_OPENVPN_PORT="53"`,
+wired to gluetun `OPENVPN_ENDPOINT_PORT`, and re-enabled `vpn-egress`. Port-forwarding is an over-tunnel PIA
+API call, unaffected by the transport port. (WireGuard fallback would also have worked — PIA WG is UDP/1337,
+not 1197 — but staying on Gluetun+OpenVPN is the smaller change.)

clusters/base/cluster-vars.yaml

@@ -43,6 +43,11 @@ data:
                                              # which lacks PF; NOT a US region, which also lack PF)
   CLUSTER_POD_CIDR: "10.0.0.0/8"             # Cilium cluster-pool pod CIDR (pods get 10.x); Gluetun
                                              # FIREWALL_OUTBOUND_SUBNETS = allow these to egress via the tunnel
+  PIA_OPENVPN_PORT: "53"                     # PIA OpenVPN endpoint UDP port. PIA's default is 1197, but
+                                             # this home network NATs its OWN OpenVPN server on WAN:1197, so
+                                             # outbound PIA-on-1197 replies never return (tcpdump-confirmed).
+                                             # 53 is proven to traverse this network. Valid PIA ports:
+                                             # 53, 1194, 1197, 1198, 8080, 9201. Other envs may override to 1197.
 
   # --- identity / auth (ADR-0014) ---
   KEYCLOAK_REPLICAS: "1"                     # dev 1 | prod 2 (HA)

platform/kustomization.yaml

@@ -17,13 +17,10 @@ resources:
   - cert-manager       # Let's Encrypt DNS-01 wildcard — needs SOPS `cloudflare-api-token`
   - externaldns        # auto DNS records — needs SOPS `cloudflare-api-token`
   - gateway            # Gateway API listeners (ingress; replaces Traefik)
-  # ---- Phase 3 — Egress / VPN — config COMPLETE + CORRECT (OpenVPN-UDP, SE Stockholm), but the tunnel
-  #      is BLOCKED by the ENVIRONMENT: gluetun's OpenVPN UDP/1197 packets to PIA leave the cluster
-  #      correctly (pod→node→host→WiFi, SNAT 192.168.2.103) but NO replies ever return to the host,
-  #      while host UDP/53 works — so the home router/ISP on the 192.168.2.x WiFi net drops OpenVPN
-  #      UDP. Disabled to avoid a crashloop firing false alerts. Re-enable once the network is fixed
-  #      (see DECISIONS-LOG "Phase 3 VPN — tunnel BLOCKED by home network"). ----
-  # - vpn-egress       # shared Gluetun PIA/OpenVPN-UDP egress gateway + kill-switch (ADR-0013)
+  # ---- Phase 3 — Egress / VPN (PIA OpenVPN-UDP on port ${PIA_OPENVPN_PORT}=53, ADR-0013 amendment).
+  #      NOT PIA's default 1197 — this home network NATs its own OpenVPN server on WAN:1197, which
+  #      collided with the outbound PIA-on-1197 flow (tcpdump-confirmed; DECISIONS-LOG). ----
+  - vpn-egress         # shared Gluetun PIA/OpenVPN-UDP egress gateway + kill-switch (ADR-0013)
   # ---- Phase 4 — Observability (creds provisioned via SOPS: grafana-admin, alertmanager-smtp) ----
   - monitoring         # kube-prometheus-stack + Loki + Alloy + Alertmanager
   # ---- Later phases: enabled when their phase opens ----

platform/vpn-egress/gluetun-gateway.yaml

@@ -40,6 +40,9 @@ spec:
               value: "private internet access"
             - name: VPN_TYPE
               value: "openvpn"               # OpenVPN-UDP — satisfies "protocol != TCP" (R-NET); ADR-0013 amended
+            - name: OPENVPN_ENDPOINT_PORT
+              value: "${PIA_OPENVPN_PORT}"   # NOT 1197 — the home network NATs its own OpenVPN server there,
+                                             # so PIA-on-1197 replies never return (see cluster-vars + DECISIONS-LOG)
             # PIA credentials from the SOPS secret (Gluetun's PIA OpenVPN creds env):
             - name: OPENVPN_USER
               valueFrom: