docs: Phase 3 VPN resolved (working + stable, PIA Stockholm egress)

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

DECISIONS-LOG.md

@@ -555,6 +555,18 @@ return traffic) and had me check MTU at each layer. Findings via `ping -M do` sw
   overhead → **pod MTU 1450**. OpenVPN emits ~1500-byte handshake packets → exceed 1450 → dropped (broken
   PMTUD = no ICMP back). This is why HTTPS (MSS-clamped) + small UDP (DNS/NTP) work but OpenVPN doesn't.
 
+### Phase 3 VPN — ✅ WORKING & STABLE (2026-08-23)
+gluetun (v3.41.3, custom mode, operator's IP-based PIA .ovpn) connects to PIA Stockholm and **holds**:
+egress IP `158.173.241.36` (Sweden), pod Running 0 restarts. Two final fixes after the .ovpn landed:
+- The .ovpn's `remote` must be an **IP** (gluetun's custom parser rejects the `sweden.privacy.network`
+  hostname) — operator supplied an IP-based .ovpn (from the sweden.privacy.network LB pool, 158.173.241.x).
+- **Liveness probe → exec (localhost)**: once the tunnel redirects the pod default route via tun0, the pod's
+  reply to the kubelet's *httpGet* liveness probe egressed the tunnel and never returned → probe timeout →
+  restart every ~110s despite the tunnel being up. A local `wget` exec probe stays on `lo`. (OpenVPN's
+  "route already exists / Network unreachable" logs are cosmetic — gluetun adds 0.0.0.0/0 itself; egress works.)
+Remaining Phase-3 work (later): egress-steering validation (Cilium egress-gw → tun0) + kill-switch conformance
+(R-NET-06); port-forwarding is unavailable in custom mode (Phase-6/qBittorrent — revisit then).
+
 ### Phase 3 VPN — custom .ovpn mode (the real cause: flaky server selection) (2026-08-23)
 After the MTU red-herrings, packet capture (node ens3 + host wlp4s0, GNOME OFF so it wasn't the host's own
 VPN) proved the pod CAN complete a **full** PIA handshake — a working flow (`50017 → 158.173.241.22:1198`)