Why this matters
Short one. A working access path that stops working is usually a sign the rule protecting it was only ever tested from one place.
What happened
SSH to Yavin-IV stopped responding from the usual management workstation. No changes to the host itself, no changes to the SSH daemon, nothing in the logs pointing at a service failure. The box was up. The connection just wasn’t landing.
qm terminal 500 got a console session going directly through Proxmox, bypassing the network entirely, which confirmed the VM was healthy and SSH was listening. That narrowed it to the network path, and the UFW ruleset was the obvious next stop.
The actual rule
The existing rule allowed SSH from 192.168.20.0/24, the Services VLAN. That’s correct, as far as it goes. It’s also not the only subnet with a legitimate reason to reach this host: the management workstation sits on 192.168.1.0/24, and there was never a corresponding rule for it. The access path had been working by coincidence up to that point, likely through a route that changed or a session that never actually re-tested the direct path until now.
Adding the management subnet to the allow list fixed it immediately.
The lesson
A firewall rule that was written for one legitimate source and later needs to serve a second one doesn’t fail loudly. It just quietly stops working for whoever isn’t in the rule, and the fix is usually one line once you know to look for it. Worth a periodic pass over anything scoped to a single subnet: is that still the only place this needs to work from?
Update: Yavin-IV has since moved to a fourth Proxmox node. The UFW rule lives inside the guest, so it moved with it. See A Fourth Node for Maintenance, Not Capacity.