# `[2026-09-15]` nh3-dev unreachable from the mesh at its LAN address — ts-input anti-spoof

`nh3-dev.nh3.internal` (10.100.10.50) failed from a mesh client while every
other NH3 host worked. Not DNS, not routing.

## Cause

A host that runs Tailscale installs an anti-spoof rule:

    -A ts-input -s 100.64.0.0/10 ! -i tailscale0 -j DROP

The fleet's subnet routers run `NoSNAT: true` with RFC1918 exempted from
masquerade — **deliberate source preservation, and a departure from Tailscale's
own `--snat-subnet-routes=true` default**. So a mesh client's packet reached
nh3-dev's `ens18` still sourced `100.64.x` and died there, silently. Every NH3
host that does **not** run Tailscale was unaffected, which is what made it look
like a name-resolution fault.

Control that settled it: `nh3-pve` (10.100.250.60) is off-link, needs a gateway
hop, and works fine — it has no Tailscale and therefore no `ts-input` chain.

## Fix

One rule on nh3-scale (CT 107), above the RFC1918 RETURNs in
`/usr/local/sbin/mesh-exit-masq.sh`: `-d 10.100.10.50/32 -j MASQUERADE`. Commit
`9dbd829`, canonical copy `servers/nh3-pve/mesh-exit-masq.sh`.

## ⚠ Do NOT instead advertise the /32 from nh3-dev

Tried the same day and it black-holed nh3-dev from ESH, Anaheim, FV and Irvine
while leaving its own LAN and the internet up. `ip rule` there puts `lookup 52`
at priority 5270, ahead of `main` at 32766; becoming a subnet router let table
52 capture cross-site traffic a `RouteAll: false` node has no accepted route
for. ⚠ **A one-host check against its own LAN passes cleanly** — test all four
sites. Same family as the 2026-09-06 accept-routes incident.

Related: [[2026-09-15-fv-cross-site-snat]]