lament/pantheon

one site's WG uplink has no v6 at all: NAT66-relay it through the hub instead #111

Merged

lament merged 1 commit from nat66-relay into main

2026-07-24 23:09:15 -05:00

lament commented

2026-07-24 22:44:45 -05:00

Owner

diagnosed via wiki-js's OIDC login failing intermittently: that residential uplink carries no IPv6 at all, but real dual-stack destinations (like our own id.lament.gay) still hand back a genuine AAAA - happy-eyeballs races it and ENETUNREACHes/times out before falling back to v4
- ruled out NAT64/DNS64 first - that combo solves "v6-only client reaches v4-only server," which is backwards from this: the destinations aren't v4-only, the client's uplink is just v6-less. confirmed against knot-resolver's actual dns64.lua source before building anything - it only ever synthesizes a AAAA when the real answer has none at all, so it would never have touched a genuinely dual-stack destination regardless
fix: NAT66 instead. affected spokes get ::/0 added to their hub peer's allowedIPs (networking.nix), so non-mesh v6 traffic routes through the hub over WG rather than failing locally
- the hub gains networking.nat.{enable,enableIPv6} + internalIPv6s scoped to just those hosts' WG /128s, masquerading their traffic onto its own real public v6
- externalInterface is a hardware fact, not derivable in the shared module - set per-host (static/athena/host.nix)
scoped to that specific site on purpose - other spokes (ishtar) have a working v6 uplink of their own and don't need the relay
verified live post-deploy: 4 consecutive logins through the previously-flaky path, no failures

- diagnosed via wiki-js's OIDC login failing intermittently: that residential uplink carries **no IPv6 at all**, but real dual-stack destinations (like our own `id.lament.gay`) still hand back a genuine AAAA - happy-eyeballs races it and ENETUNREACHes/times out before falling back to v4 - ruled out NAT64/DNS64 first - that combo solves "v6-only client reaches v4-only server," which is backwards from this: the destinations aren't v4-only, the client's uplink is just v6-less. confirmed against knot-resolver's actual `dns64.lua` source before building anything - it only ever synthesizes a AAAA when the real answer has none at all, so it would never have touched a genuinely dual-stack destination regardless - fix: NAT66 instead. affected spokes get `::/0` added to their hub peer's `allowedIPs` (`networking.nix`), so non-mesh v6 traffic routes through the hub over WG rather than failing locally - the hub gains `networking.nat.{enable,enableIPv6}` + `internalIPv6s` scoped to just those hosts' WG `/128`s, masquerading their traffic onto its own real public v6 - `externalInterface` is a hardware fact, not derivable in the shared module - set per-host (`static/athena/host.nix`) - scoped to that specific site on purpose - other spokes (`ishtar`) have a working v6 uplink of their own and don't need the relay - verified live post-deploy: 4 consecutive logins through the previously-flaky path, no failures

lament added 1 commit

2026-07-24 22:44:45 -05:00

one site's uplink has no v6 at all: NAT66-relay it through the hub instead of NAT64/DNS64

CI / check (pull_request) Successful in 1m46s

Details

CI / deploy (pull_request) Has been skipped

Details

CI / build (pull_request) Successful in 3m4s

Details

CI / dry-activate (pull_request) Successful in 29s

Details

7798d216ad