---
name: ad2-ssh-mtu-blackhole
description: AD2 SSH "lockouts"/mid-session timeouts over the Dataforth OpenVPN were an MTU/PMTU blackhole, not a ban/account-lockout/flaky tunnel; fix = pin the tunnel adapter MTU to 1400
metadata:
  type: project
---

AD2 (Dataforth, `192.168.0.6`) SSH from the fleet over OpenVPN (client subnet `192.168.6.x`)
intermittently looked "locked out": sessions **authenticated fine**, then died mid-session with
`Read error from remote host 192.168.6.2 ... Unknown error [postauth]` and
`ssh_dispatch_run_fatal: Connection from authenticating user sysadmin ... Connection timed out [preauth]`.
Small/interactive commands often worked; bulk reads + `scp` stalled.

**Root cause (diagnosed 2026-06-18 via RMM — SSH itself was the failing channel, so don't diagnose it over SSH):**
- NOT account lockout — Windows lockout threshold is 5/30min but **zero 4740 events**; `sysadmin` never locked.
- NOT an IP ban — **no IPBan/wail2ban/RdpGuard**, **0 inbound firewall block rules**.
- NOT auth — **every** `Accepted publickey for sysadmin` succeeded.
- NOT load — AD2 was CPU ~11%, 11.7 GB RAM free.
- It was a **PMTU blackhole.** OpenVPN tunnel path MTU is **~1424** (DF ping: wire 1424 passes,
  1428 drops). But GURU-5070's OpenVPN adapter (`Local Area Connection`, ifIndex 12, IP
  `192.168.6.2`) was set to **MTU 1500** → TCP negotiated MSS 1460 → full-size bulk/scp segments
  exceeded the tunnel and were **silently dropped (DF set)**, while sub-MTU interactive packets
  passed. That is why it presented as random "lockouts" that got worse with bulk transfer.

**Fix applied (2026-06-18):** `Set-NetIPInterface -InterfaceIndex 12 -AddressFamily IPv4 -NlMtuBytes 1400`
run via **GURU-5070's own RMM agent** (`819df0c8...`, runs as `nt authority\system` = elevated; the
elevated lever on the local box when you can't self-elevate from the Claude shell). Validated: a
**1.41 MB single-session SSH transfer to AD2 completed in 9s, no read error** (previously blackholed).
`~/.ssh/config` `ad2` block annotated + tightened keepalives (`ServerAliveInterval 15`,
`ServerAliveCountMax 4`, `ConnectTimeout 20`).

**Durability / permanent fix:** `Set-NetIPInterface` is registry-persistent, but **OpenVPN Connect may
reset the adapter MTU to 1500 on reconnect** — re-apply if SSH bulk transfers start stalling again
(check `Get-NetIPInterface -InterfaceIndex 12`). The real permanent fix is **server-side on the
Dataforth OpenVPN server: `mssfix 1360` (or `push "tun-mtu 1400"`)** so every fleet client clamps
automatically — `192.168.6.4` showed the identical symptom, so this is fleet-wide, not 5070-only.

Corrects the earlier wrong attribution ("flaky VPN tunnel" / "my rapid scp+ssh bursts triggering a
ban") — the tunnel is up and stable for small packets; only over-MSS segments were dropped. See
[[prefer-ssh-over-rmm]] (RMM-as-fallback guidance still holds; the *reason* was MTU, not a flaky VPN).