fix(vpn): disable vpn-egress — network blackholes PIA IPs (not ports/MTU/cluster)
Decisive diagnosis: OpenVPN's outbound init packets are 14 bytes with zero replies (so MTU was never the blocker), pod UDP egress is healthy (NTP replies), but TCP 501/443 to PIA IPs time out while Google/Cloudflare are OPEN — across many PIA servers. This 192.168.2.x WiFi segment blackholes PIA's IP ranges (and intercepts DNS). Not code-fixable. Reverted the port/MTU red-herring env to PIA defaults; disabled vpn-egress pending an operator network fix (move to the unfiltered 192.168.1.x LAN, or unblock PIA on the router). Full trace in DECISIONS-LOG. Co-Authored-By: Claude Opus 4.8 <[email protected]>
This commit is contained in:
1 parent
9fc117e06d
commit
95a55952cc
4 files changed
+34
-21
No files matched your search
@@ -560,3 +560,24 @@ return traffic) and had me check MTU at each layer. Findings via `ping -M do` sw
|
||||
Cilium VXLAN unchanged. Port kept at 8080 (confirmed PIA responds). Re-enabled `vpn-egress`. Values hardcoded
|
||||
as quoted strings (int-coercion gotcha). Alternatives not taken: Cilium native routing (pod MTU→1500) or
|
||||
WireGuard/thrnz (MTU-robust) — both still available if the MTU shrink proves insufficient.
|
||||
|
||||
### Phase 3 VPN — ACTUAL ACTUAL root cause: the network blackholes PIA's IP ranges (2026-08-22)
|
||||
The MTU shrink did NOT fix it. A node-side tcpdump of the handshake was decisive: OpenVPN's outbound init
|
||||
packets are **14 bytes** (nowhere near any MTU) and get **zero replies** — so MTU was never the handshake
|
||||
blocker either. Confirmed pod UDP egress is healthy (pod NTP/123 reply OK). Then the real test — raw
|
||||
TCP/ICMP reachability to PIA IPs vs controls (from host AND pod):
|
||||
- **PIA** (46.246.8.55, 212.112.19.22): TCP **501 and 443 time out** (silent drop, not refused), UDP no
|
||||
reply, ICMP no reply — across many PIA servers gluetun cycled.
|
||||
- **Google / Cloudflare**: TCP/443 OPEN, UDP replies, ICMP replies.
|
||||
|
||||
→ **This network (192.168.2.x, WiFi) blackholes traffic to PIA's IP ranges.** It also transparently
|
||||
intercepts DNS/:53. Everything else (HTTPS, DNS-via-proxy, NTP, general internet) works. So it is neither
|
||||
ports, nor MTU (both red herrings — the Cilium VXLAN 1450 pod MTU is real but irrelevant to a 14-byte
|
||||
handshake), nor the cluster/config — it is upstream network filtering of PIA specifically.
|
||||
|
||||
**Action → operator (network, not code):** move the k3s host to the unfiltered main LAN (192.168.1.x /
|
||||
wired), or unblock PIA's ranges on the 192.168.2.x router, then re-enable `vpn-egress` (no code change).
|
||||
WireGuard/thrnz would NOT help — same PIA IPs are blocked; if switching providers is ever considered, pick
|
||||
one whose ranges this network permits. Reverted the port/MTU red-herring env from gluetun-gateway.yaml
|
||||
(back to PIA defaults); `vpn-egress` disabled so it doesn't crashloop/alert. **Config is correct and
|
||||
complete — the only blocker is the network.**
|
||||
Reference in new issue
Block a user