Merge feature/vpn-blocked-network into main

This commit is contained in:
jakman85 committed 2026-08-22 15:05:21 -05:00
commit 347f7a54b6
2 files changed
+30 -2

No files matched your search

+23
View File
@@ -484,3 +484,26 @@ breaks the SOPS MAC); cosmetic.
**Next:** confirm the OpenVPN tunnel comes up + correct egress IP, then egress-steering validation (README
option 1, `tun0`) + kill-switch conformance (R-NET-06).
### Phase 3 VPN — tunnel BLOCKED by home network (2026-08-22)
After deploying OpenVPN + fixing the region (`SE Stockholm`), gluetun goes **Running** and OpenVPN dials
PIA Sweden servers over **UDP/1197**, but the handshake never completes — no `TLS: Initial packet from`
the server, gluetun healthcheck restarts it in a loop. **Not auth** (no `AUTH_FAILED`), **not a k8s
NetworkPolicy** (vpn-egress is `app-namespace=false`, no policies touch it), **not the cluster/host path**.
Traced with tcpdump end-to-end:
- On the node (k3s-dev-3): pod `10.0.2.161` → Cilium SNAT → `ens3 Out 10.73.0.13 > 46.246.x:1197`. Leaves fine.
- On the host: `virbr1 In 10.73.0.13 > 46.246.x:1197` → `wlp4s0 Out 192.168.2.103 > 46.246.x:1197`. Host
NATs it out the **WiFi** onto the `192.168.2.x` home LAN. Leaves fine.
- On the host `wlp4s0`, filtering `src net 46.246.0.0/16`: **0 reply packets in 20s.** Meanwhile host
UDP/53 (`dig @9.9.9.9`) works. → OpenVPN UDP replies never return to the host.
**Conclusion:** the break is UPSTREAM of the host — the home router/ISP on the `192.168.2.x` WiFi network
is dropping/not-returning OpenVPN UDP/1197 (TCP egress + UDP/53 both work; only the VPN UDP is affected;
this box is on 192.168.2.x via WiFi, not the main 192.168.1.x LAN). **Environmental, outside the repo.**
**Action → operator:** fix at the network (check the 192.168.2.x router for outbound UDP/1197 or VPN
filtering; try a wired connection to the main 192.168.1.x LAN; or a different port/provider). No in-config
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).
+7 -2
View File
@@ -17,8 +17,13 @@ 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 (PIA creds provisioned via SOPS; OpenVPN-UDP per ADR-0013 amendment) ----
- vpn-egress # shared Gluetun PIA/OpenVPN-UDP egress gateway + kill-switch (ADR-0013)
# ---- 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 4 — Observability (creds provisioned via SOPS: grafana-admin, alertmanager-smtp) ----
- monitoring # kube-prometheus-stack + Loki + Alloy + Alertmanager
# ---- Later phases: enabled when their phase opens ----