---
name: windows-runner-firewall-drops-cold-inbound-to-rule-less-test-exes
description: hfenduleam Windows Firewall is BlockInbound; runner-built test exes (service, no Allow dialog) get no rule, so a peer's COLD inbound UDP to a rig daemon is dropped for the whole budget and the panic blames pairing/product — measured 2026-09-08 (0/3 vs 3/3 control)
metadata:
  type: project
---

**Measured 2026-09-08 21:11Z (doyle, #272 golden r2 terminal):** twohost r2 red both halves, B 75 × "A not ready … 10s bound (peer unresponsive)" for all 900 s with the per-cell-identity fix already in the sha. Cause = hfenduleam Windows Firewall `BlockInbound,AllowOutbound` on all profiles; inbound allow rules exist only for exes under `Documents\projects\spt-core\target` (interactive clicks) and the DEAD pre-rename `_work\spt-core\spt-core` path; ONE under `_work\spt-bs-core` (spt.exe, the CLI — not the binder; I had said zero, deployah counted), none for `twohost_web-*.exe`. `DefaultInboundAction=NotConfigured` = Windows' default block, not a set policy. Probe: rule-less pwsh UDP listener on hfenduleam:7483, 3 datagrams from kitsubito → 0 received; reverse control → 3/3.

**Why:** the runner is a service (`.\decid`), so the Allow dialog never appears; program-path rules die on every exe-hash change and on a repo rename. Any rig claim that travels INTO the Windows runner cold (no prior outbound from that port) is dropped silently; the old shared-key rig only got through on holes its own outbound dials had opened — which is why the "helper stall" wore three faces (63 s, 21 min hang, 900 s never) from one cause, and why a one-box discriminator "vanishes" without meaning anything about the box.

**How to apply:** before ruling a "peer unresponsive / never converged" red on a cross-box rig as product or timing, run the UDP probe both directions (rule-less listener on the Windows side; `python3 -c sendto` from the Linux side) — 30 s, no elevation needed. The FIX needs an elevated operator command (scoped port+remote rule, IR-82); I am not elevated on hfenduleam and `sudo` is disabled. First A-ward claim of any rig = expect this. Kin: [[twohost-web-helper-stall-shared-a-identity-stale-path]], [[never-send-a-claim-composed-before-its-check-ran]].

**CORRECTION 2026-09-08 23:50Z — ONE LAYER SHORT.** The operator applied the Windows rule exactly as asked; re-probe STILL 0/3. Second layer = the tailnet ACL: same listener 3/3 over LAN, 0/3 over Tailscale (UDP and TCP); `tailscale debug netmap` shows kitsubito (tagged `tag:eye-tracking-resource`, other tailnet user) is NOT a permitted inbound source to hfenduleam while the reverse is. Windows rule necessary, not sufficient. Rule: after ANY fix, the meter is the probe over the rig's own path reading 3/3, never "the rule exists"; and when a Windows-firewall story explains a drop, test the LAN path against the tunnel path before naming the layer — that split costs 30 s and I did it only after the operator had already acted on my incomplete ask.

**RESOLVED 2026-09-08 ~23:5xZ — and NOT by the fix this file predicted.** The write-up above expects
an elevated `New-NetFirewallRule` on hfenduleam (program- or port-scoped). What actually cleared it
was an OPERATOR TAILNET ACL: the netmap now carries `kitsubito -> hfenduleam udp 7460-7499`, and
doyle's Tailscale probe reads 3/3 on both 7483 and 7489 (same probe that read 0/3 before). No
Windows Firewall rule was added, and the box's `BlockInbound` posture is unchanged.

**Why this matters for the next hunt:** the drop was on the tailnet path, so a host-firewall rule
would have been the right shape aimed at the wrong layer — and it would have "worked" only by
opening the host more widely than the ACL does. Two candidate layers can produce one identical
symptom (0/3 cold inbound), and the probe that measures the symptom does not name the layer.

**How to apply:** when a cold-inbound probe reads 0/3 between two tailnet peers, ask which layer
before writing a fix — check the tailnet ACL / netmap for the port range FIRST (it is the cheaper
and narrower of the two, and needs no elevation on the receiving box), then the host firewall.
State the layer you MEASURED, not the one the symptom resembles. Recorded by todlando from doyle's
23:59Z GO message; the range and the 3/3 are his figures, not my own probe.