I enabled ufw and now SSH won't connect. Did I lose the server?

No. The server is running fine — you just blocked the door from the inside. Your data is untouched. Open the web console in your control panel (it logs you in without SSH) and run `sudo ufw disable`, and you're back. No reinstall needed.

Why did enabling ufw kill my SSH?

ufw defaults to denying all incoming traffic, and if you enabled it without first allowing your SSH port, your own session gets cut. It's the single most common self-inflicted lockout. Always `ufw allow ` before `ufw enable`.

How do I fix ufw if I can't SSH in at all?

Use the out-of-band web console (serial console) in your panel — it doesn't go over SSH or even need the network stack, so a firewall rule can't block it. Log in there, then `sudo ufw disable` (fastest) or `sudo ufw allow ` to fix the specific rule.

On a NAT VPS, which port do I allow in ufw?

Allow 22, not the external port. On a NAT plan you connect on a high port like 20266, but that's forwarded to port 22 inside the VM. ufw runs inside the VM and only sees 22. Allowing 20266 does nothing; allow 22.

Is `ufw reset` safer than `ufw disable`?

`disable` just turns the firewall off and keeps your rules — quickest way back in. `reset` wipes every rule to defaults. Use `disable` to recover, then re-add rules carefully. Only `reset` if the ruleset is a mess you want gone.

Locked out of your VPS by ufw? Get back in without a reinstall

There's a rite of passage for anyone new to running their own server: you decide to set up a firewall, you type a few ufw commands, you hit enable — and your terminal goes silent. SSH is gone. You didn't crash anything, you didn't get hacked. You just locked the door with yourself outside.

It happens to good sysadmins too. It happened to one of our customers last week, which is why I'm writing this down. The good news: it's completely recoverable in under a minute, and you do not need to reinstall or lose a single file. Here's how.

A VPS sealed behind a firewall wall, with a glowing console window as the way back in

What actually went wrong

ufw (Uncomplicated Firewall) defaults to deny all incoming. The moment you run ufw enable, anything you didn't explicitly allow is dropped — including the SSH session you're sitting in. If you forgot to ufw allow your SSH port first, you've cut your own connection the instant the rule takes effect.

That's the classic version. There are two other flavours that catch people:

You allowed the wrong port. Typo, or you allowed the service port (say 8080) and forgot 22.
You allowed 22 but then set a deny rule higher in the list that shadows it. ufw is order-sensitive.

Either way the server itself is fine — running, disk intact, your app still humming behind the wall. It's purely a network-access problem. Which is exactly why the fix is easy.

The wrong move: reinstalling

The first instinct is often "just reset the server and start over." Don't — not for this. A reinstall wipes everything to get back a working SSH, when the thing blocking SSH is one firewall command you can undo in ten seconds. You'd be burning down the house because you locked the front door.

Reinstall is the right call when you want a clean slate. For a ufw lockout, it's overkill.

The right move: the web console

Every VPS worth its salt gives you an out-of-band console — a way into the machine that doesn't ride over SSH or even the network stack. On EQVPS it's the Console button on your server's page. It's a serial console: text-only, connected straight to the VM the way a monitor and keyboard would be. A firewall rule has no power over it, because it isn't network traffic.

Click it, log in with your root credentials (or reveal the password in the panel if you don't have it handy), and you're on the box — firewall or no firewall.

Now undo the damage. Fastest path:

sudo ufw disable

That turns the firewall off and keeps your rules, so you can re-enable it later once you've fixed the mistake. SSH comes straight back.

If you'd rather not drop the firewall entirely, just open the port you missed:

sudo ufw allow 22
sudo ufw status numbered

The status numbered view is worth a look — it shows the rule order, which is where the "I allowed 22 but it still blocks" cases hide. If a deny sits above your allow, delete it with sudo ufw delete <number>.

The NAT gotcha most guides miss

If you're on a NAT plan, there's a trap here. You SSH in on a high port — something like 20266 — so the natural instinct is ufw allow 20266. That does nothing.

On NAT, that external port is forwarded to port 22 inside the VM. ufw runs inside the VM and only ever sees 22. So the rule you actually need is:

sudo ufw allow 22

Allow 20266 and you'll stare at a still-broken connection wondering why. Allow 22 and you're in. Same idea for any service: allow the port the process listens on inside the box, not the forwarded one you connect to from outside.

How to never do this again

The fix takes a minute, but not needing it is nicer. Two habits:

Allow your SSH port before you enable. In this order, always:

sudo ufw allow 22
sudo ufw enable

Do it backwards and you're back in the console.

Keep a second session open while you change firewall rules. Log in twice. Make your changes in one window; if SSH dies, the other window is still alive to fix it. Old trick, saves you every time.

And if you're setting up a fresh box, our new-VPS security checklist covers ufw the right way round, alongside SSH keys and the handful of other things that actually matter in the first ten minutes.

The takeaway

A ufw lockout looks scary and is almost nothing. The server never left; you just need a door that a firewall can't slam — the web console — and one command. Keep ufw disable and the console in your back pocket, allow your port before you enable next time, and you'll never sweat this one again.