Locked out of my own server by a deny-all rule

The scenario

Admin-PC (10.0.1.10) manages Server (10.0.2.10) over SSH, and Office-PC (10.0.1.20) uses the website Server hosts on HTTP. Both PCs sit on the office switch behind Firewall. Firewall has three rules: allow TCP port 22 only from 10.0.1.10/32 (priority 10), allow TCP port 80 from anyone (priority 20), and a deny-all added at priority 1 'for security'. Rules are checked lowest number first and the first match wins, so the deny-all matches every packet and neither allow rule is ever reached. The admin is locked out, and so is everyone else.

What you will work out

Learn why a deny-all must come after the allows, how a source address narrows an allow rule, and how admins avoid locking themselves out.

Why this matters

Lockouts usually come from a well-meant change applied in the wrong order, often on a device you can only reach through the network you just blocked. Two habits prevent most of them: write the specific allows before the broad deny, and keep a way back in (a console port, a provider console, or an automatic rollback) before you apply the change. The same ordering applies to iptables, Cisco ACLs and AWS network ACLs.

Running it

Accidental Lockout: Locked Out of My Server opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.