vh/esh-pfi-infrastructure
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

fix(fv): broaden the Tailscale SNAT rules from fv-ml1/32 to the FV LAN /24

Browse Source 
All four outbound-NAT rules on the FV gateway now match source
10.251.50.0/24 instead of fv-ml1's single address, so a second host at FV
works on arrival rather than reproducing a failure whose symptoms point at
routing rather than NAT.

Anaheim got a /24 rule of its own through the API. The 2026-09-13 ANA rule was
written with write_config and is invisible to source_nat/search_rule, so
leaving it as the only ANA coverage would have kept one destination on a
different code path from the other three. The legacy /32 rule is now redundant
but harmless -- it NATs identically and first-match wins -- and is noted in the
runbook for deletion from the UI, since it is the one rule the API cannot see.

Descriptions rewritten to name the real scope. Three of them said "fv-ml1 to X"
while covering the whole subnet, and a description that understates a rule's
reach is the same trap as the Anaheim-only scope that caused this.

Verified after: fv-ml1 reaches NH3, nh3-dev, ESH, Anaheim, Irvine, the mesh and
the internet; nh3-dev, esh-docker-vm and ana-docker all reach FV and each
other; the FV BMC remains reachable inbound. Pre-change config backup taken.

Also records that 10.251.250.0/24 (BMC/management) is deliberately NOT covered
-- inbound reachability is what out-of-band recovery needs, but a management
host originating traffic to another site would hit this same wall.
This commit is contained in:
Vuong Hoang
2026-09-15 00:47:00 -07:00
parent fa04f450fb
commit 0ab9da5b89
1 changed files with 27 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/runbooks/fv-to-ana-nat.md
+27 -3
View File
@@ -37,9 +37,33 @@ pre-change `core/backup/download/this` taken first. After: fv-ml1 reaches all
four sites, the mesh and the internet; nh3-dev, nh3-docker and esh-docker-vm
regression-swept clean.
⚠ **The source is still `10.251.50.54/32` — fv-ml1 only.** A second host at FV
will have exactly this problem and no symptom that points at NAT. Broaden to
`10.251.50.0/24`, or add a rule per host, when FV grows.
### Broadened to the whole FV LAN, same session
All four rules now carry source **`10.251.50.0/24`** rather than fv-ml1's `/32`,
so a second host at FV works on arrival instead of reproducing this failure with
no symptom that points at NAT. Anaheim got a `/24` rule of its own through the
API for the same reason — the 2026-09-13 rule was written with `write_config`
and is invisible to `source_nat/search_rule`, so leaving it as the only ANA
coverage would have kept one destination on a different code path from the
other three.
src=10.251.50.0/24 dst=10.100.0.0/16 FV LAN 10.251.50.0/24 to NH3 via Tailscale SNAT
src=10.251.50.0/24 dst=10.0.0.0/16 FV LAN 10.251.50.0/24 to ESH via Tailscale SNAT
src=10.251.50.0/24 dst=10.6.110.0/24 FV LAN 10.251.50.0/24 to IRV via Tailscale SNAT
src=10.251.50.0/24 dst=10.250.0.0/16 FV LAN 10.251.50.0/24 to ANA via Tailscale SNAT
Descriptions were rewritten to name the actual scope. A description that
understates a rule's reach is the same trap as the Anaheim-only rule itself.
⚠ **The legacy `/32` ANA rule still exists** in `config.xml` and is now
redundant. Harmless — it NATs identically and first-match wins — but it is the
one rule the API cannot see, so delete it from the UI when convenient rather
than wondering later why the counts disagree.
⚠ **`10.251.250.0/24` (BMC / management) is NOT covered.** The rules are scoped
to the server VLAN only. The BMC is reachable inbound from the fleet, which is
what matters for out-of-band recovery, but a management-VLAN host originating
traffic to another site would hit this same wall.
### What this looks like when it breaks, so the next person skips the evening