diff --git a/docs/14-HERDR-REMOTE-MACHINES.md b/docs/14-HERDR-REMOTE-MACHINES.md
index 6b45000..911359b 100644
--- a/docs/14-HERDR-REMOTE-MACHINES.md
+++ b/docs/14-HERDR-REMOTE-MACHINES.md
@@ -52,7 +52,41 @@ exec ssh -T -o BatchMode=yes -o ConnectTimeout=10 \
     "export XDG_RUNTIME_DIR=/var/run/herdr-rt; mkdir -p \"\$XDG_RUNTIME_DIR\" && chmod 700 \"\$XDG_RUNTIME_DIR\"; $*"
 ```
 
-## Why the LAN address and not the Tailscale IP
+## Working from outside the LAN
+
+No extra configuration is needed. The transport targets `192.168.10.20:422`, and
+a Mac away from home reaches that over Tailscale via the `mikrotik-tailscale`
+subnet router, which is primary for `192.168.10.0/24`. This is not a special
+remote mode — it is the same path used on VLAN 20 at home, since that is also a
+different subnet from Unraid.
+
+Prerequisites on the client:
+
+| Requirement | Check |
+|-------------|-------|
+| Tailscale running and logged in | `tailscale status` |
+| Accepts the hAP's subnet routes | `tailscale debug prefs` shows `"RouteAll": true` |
+| Route resolves over Tailscale | `route -n get 192.168.10.20` reports `utun*`, not `en0` |
+
+### Fallback leg
+
+The LAN path depends on the `mikrotik-tailscale` container, which has failed
+before (see the 2026-08-10 recovery note in `docs/09-TAILSCALE-VPN.md`). If it
+dies while Unraid stays up, `192.168.10.20` becomes unreachable over Tailscale
+but Unraid's own node does not.
+
+So the wrapper probes `192.168.10.20:422` first and falls back to Tailscale SSH
+on `100.100.208.69:22`. The probe runs **before** any ssh starts, because a
+failed first attempt would consume stdin and corrupt the retry. It costs about
+245 ms on the success path. `HERDR_VIA_TARGET=lan|ts` forces a leg for testing;
+both were verified 2026-11-03.
+
+The fallback leg inherits the tailnet ACL caveat below: with the default
+`action: "check"` it works until the grant lapses, then wants a browser
+re-auth. Setting that rule to `accept` for `autogroup:self` makes the fallback
+fully unattended.
+
+## Why the LAN address is the primary and not the Tailscale IP
 
 `--via` requires a transport that passes bytes untouched and **asks nothing**.
 Tailscale SSH on `100.100.208.69` sits behind the default tailnet ACL