USEFUL, ACTUALLY
Ubuntu · Firewall

Repair UFW without locking yourself out

On a remote machine, protect the actual SSH path and prove a second connection works before deleting or resetting any rule.

Checked 13 Aug 2026Ubuntu Server / UFWSafety-sensitive
Before changing anything

Keep the current SSH session open. Confirm provider-console or physical recovery access, identify the SSH port you actually use, verify its allow rule, and open a second SSH session successfully. Only then remove the smallest faulty rule.

Remote-server warning: do not follow this guide if SSH is your only access path and you cannot open an independent console. A firewall mistake can disconnect you immediately.

Use the smallest-change sequence

  1. Record the current state.
    Run sudo ufw status verbose and sudo ufw status numbered. Save the output. Also record the SSH port and source IP or management-network CIDR from your known working connection; do not assume port 22.
  2. Confirm a recovery path.
    Open the cloud provider’s serial/web console or confirm physical access before changing rules. If no independent recovery path exists, stop.
  3. Preview and preserve the existing SSH path.
    Replace both placeholders with values from the connection you already use: sudo ufw --dry-run allow proto tcp from <MANAGEMENT_IP_OR_CIDR> to any port <SSH_PORT>. If the preview is correct, run it again without --dry-run. Do not broaden a previously restricted management path to every source address.
  4. Verify the installed rule and a new connection.
    Run sudo ufw status numbered and confirm the source range and destination port. Keep the first session open and connect from a second terminal on that permitted path. A dry run is not a connectivity test. Do not continue until the second session succeeds.
  5. Delete only the faulty rule.
    Prefer deleting by the original rule syntax when you need matching IPv4 and IPv6 rules removed together. If you delete by number, only that selected entry is removed; run sudo ufw status numbered again after every deletion because the numbers change.
  6. Test after each change.
    Open another new SSH connection and check the affected service before making the next edit.

Treat reset as recovery work, not cleanup

The Ubuntu Jammy UFW manual states that ufw reset disables UFW and resets it to installation defaults. On a remote server, use it only from an independent console with a written rebuild sequence. Re-add the verified SSH allow rule before enabling UFW, then test from a separate session.

Sources and limits

The status, numbered-rule, delete, allow, and dry-run patterns are covered by current Ubuntu Server documentation. Reset and dual-stack cautions are scoped to the Jammy UFW manual. Cloud firewalls, nftables rules, containers, and customized SSH configurations can change the result. No live-server test was performed.

Something unclear or outdated?

Tell us what failed, including your operating system or app version. We review corrections against current primary sources.

Send a correctionRelated: Diagnose a local firewall pathAll answers