UFW Lock Me Out: How I Fit Enter My VPS Again

Enter back first

If ufw lock you out from your VPS, na provider console or rescue mode be the way to enter again, because no SSH-based fix fit work once the blocking rule don become active. The kernel drop your packet before sshd ever see am, so nothing dey for you to log in to and nothing fit repair through the network. Open the console for your provider control panel, log in for that prompt, then run one command.

sudo ufw disable

You suppose see Firewall stopped and disabled on system startup. New SSH connections go work again within one or two seconds. Nothing wey you configure don lost: disable unload the rules from the kernel and write ENABLED=no into /etc/ufw/ufw.conf, while your rules remain for disk inside /etc/ufw/user.rules, waiting for the next ufw enable.

No reboot and hope say e go fix am. ufw start by itself during boot, so ENABLED=yes mean say the same ruleset go load again before the network come up. Reboot no change anything about ufw lockout.

Console need password wey you fit no get

Web console (VNC or serial) na keyboard wey connect to the machine. E no be network path, so no firewall rule fit block am. But e need local login. Na here key-only setup dey fail: if you never set password for your sudo user, and root login dey locked, console go show prompt wey you no fit answer. Set that password now, while SSH still dey work: sudo passwd yourname. Most panels fit also reset root password, and normally this one go force reboot.

If console no usable, boot the provider rescue system. E dey run separate operating system with your disk unmounted, so you fit turn ufw off from outside.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Run lsblk first, because root partition no always be /dev/vda1. Reboot into the normal system, and ufw go remain off until you enable am by hand.

The small recovery steps

Follow dem for this order. The first four steps safe. The one after dem no safe.

1. sudo ufw disable to unload the rules and get your access back.
2. sudo ufw show added to print the rules wey you add, as the commands wey add dem. E dey work while ufw inactive, but ufw status no dey work.
3. sudo sshd -T | grep -i '^port' to confirm the port wey sshd really dey listen on. E print port 22 unless you change am.
4. sudo ufw allow 22/tcp, using your real port, so the next enable no go repeat the lockout.
5. sudo ufw enable, but schedule rollback first. You go see how to do that further down this page.

Wetin ufw reset really dey do

ufw reset na last resort, no be first step. E go disable firewall, back up every rules file, and return the defaults to deny incoming and allow outgoing. E go print one backup line for each file:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

After reset, you no get any allow rules again. So run am from console instead of SSH, then add the SSH rule before you enable firewall again. Those backups na plain text. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 go show the old rules, and na so you fit rebuild ruleset wey you no intend throw away.

Where ufw dey keep im rules

To read the files better pass to guess from memory. Five paths hold the complete state:

• /etc/ufw/user.rules and /etc/ufw/user6.rules: na the rules wey you add, for the order wey dem dey evaluate.
• /etc/ufw/before.rules and /etc/ufw/after.rules, plus the 6 variants: na the framework wey ufw wrap around your rules, including the accept rule for established connections and the loopback rules.
• /etc/default/ufw: na the default policies and the IPV6 switch.
• /etc/ufw/ufw.conf: ENABLED and the log level.
• /var/log/ufw.log: na wetin dem block, once logging don turn on.

ufw dey write timestamped copy of file before e rewrite am, so ls /etc/ufw/ go fill with names like user.rules.20260813_101500. Na your undo history be that, and e good make you read am before you start change things back.

To see wetin load for the kernel instead of wetin dey disk, use sudo ufw show raw, or sudo iptables -S and sudo ip6tables -S. For Ubuntu 22.04 and 24.04, those commands na the nft-backed versions, so sudo nft list ruleset go print the same rules with the newer syntax.

Why ufw enable make my SSH session drop?

The default policy for incoming traffic na deny. If you enable ufw without rule for your SSH port, e go cut off every new connection. ufw dey warn you: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Answering y without SSH allow rule in place na the most common reason for everything wey dey this page.

The confusing part na the delay. /etc/ufw/before.rules dey accept packets wey get ESTABLISHED,RELATED state before e reach your own rules, so the session wey you use run the command go continue to work normally. The lockout go only show for the next connection, and that one fit happen hours later. By that time, the firewall change no longer look related. Always open another SSH session and confirm say e dey work before you close the first one.

Why apt and DNS stop working after policy change?

sudo ufw default deny outgoing dey block outbound DNS (domain name system) queries and outbound HTTP, so name resolution dey fail and package updates stop. apt update dey report Temporary failure resolving 'archive.ubuntu.com'. Inbound SSH still dey work because replies to am dey ESTABLISHED and dey pass the framework rules. This one make firewall look innocent even though na e cause the problem.

If you want deny outgoing policy, open the things wey the machine really need:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Without the last rule, clock go drift. Wrong clock dey break TLS (transport layer security) certificate validation, so curl go start fail because of dates instead of ports. This symptom fit show up days after the change. Na why deny outgoing policy dey suitable for machines wey you dey monitor, not box wey you set up once.

Why my ufw rule no dey match?

ufw dey evaluate user rules in order, then e dey stop for the first match. A deny wey you add after broad allow no go ever apply, because the allow don already decide wetin go happen to the packet. Print the order with numbers, then insert am for the position wey you need.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp dey print the rules wey e for write, but e no dey change anything. Na the safe way be this to read rule before e go live.

Another trap dey inside the application profiles. sudo ufw allow OpenSSH dey use the profile for /etc/ufw/applications.d/openssh-server, and that profile mean port 22. If sshd dey listen on 2222, the rule go open port wey no process dey use, and e fit lock you out even though the ruleset look correct. Use the port number after you don move the port. The remaining syntax dey covered for ufw firewall basics for VPS.

Why IPv4 rules no dey explain wetin I dey see?

Because half of the traffic no be IPv4. Ubuntu dey ship IPV6=yes for /etc/default/ufw, and ufw dey keep separate v6 ruleset for /etc/ufw/user6.rules. Rule wey you write with IPv4 address, like ufw allow from 203.0.113.10 to any port 22, no dey create any v6 rule. If your VPS get AAAA record, your client go prefer IPv6, and your connection go time out while ufw status dey show rule wey look correct. Test the difference with ssh -4 user@host against ssh -6 user@host. If the first one work and the second one no work, na the v6 ruleset cause the gap.

The reverse case worse for security. With IPV6=no, ufw no dey manage ip6tables at all, so the v6 policy remain for the kernel default of ACCEPT. Port wey you believe say e close go answer for its IPv6 address, and no ufw command go ever mention am. Check with sudo ip6tables -S and ss -tlnp, then read how ufw dey handle IPv6 ports for the complete picture.

Why Docker port open dey when ufw deny am?

Docker dey publish port by writing DNAT (destination network address translation) rules inside the nat table, then e dey insert im own chain inside FORWARD. ufw rules dey for the INPUT path. Traffic wey dey go container dey forwarded instead of dem delivering am to host, so e no ever reach the chain where your deny rule dey. docker run -p 5432:5432 fit reach internet even when ufw dey active and dey deny everything.

sudo iptables -t nat -S DOCKER

The simplest fix na to publish am on loopback: -p 127.0.0.1:5432:5432 go bind the host side to 127.0.0.1, and nothing external fit reach am, no matter wetin ufw talk. How Docker dey publish ports around ufw cover the cases where the service really need make e public.

Schedule rollback before you apply the rule

Na this habit dey make firewall work survivable. Before you make any risky change, schedule how to undo am. If the change lock you out, the machine go fix itself after five minutes, and you no need open the console.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd go print Running timer as unit: ufw-rollback.timer. Now make your change. If you still fit open new SSH session after that, cancel the rollback:

sudo systemctl stop ufw-rollback.timer

If you no fit open that session, wait. ufw go stop by itself, and your next attempt go connect. The usual shutdown -r +5 trick no dey help with ufw, because ufw loads the same ruleset again when system boot.

Keep second way enter

• Log in to the provider console once, before you need am, and confirm say the password dey work. Console wey you never test no be backup.
• Keep second sudo user with e own key, so one broken authorized_keys file no go end your access.
• Check whether your provider dey run network firewall for the panel, separate from ufw. E dey block the same ports, and ufw status no go ever mention am.
• No make ufw allow from <your home address> be your only SSH rule if that address dey change. Your provider fit change am overnight and you go lock yourself out.

The cheapest time to do all this na when server still fresh, together with the other setup work for the first ten minutes for new VPS.

Refused or timed out show you which layer fail

Connection refused mean say packet reach the server and something send TCP reset back. The network path dey okay, so sshd stop or e dey listen for another port. Firewall rarely be the cause, because ufw dey drop by default instead of rejecting.

Connection timed out mean say nothing come back at all. Na the signature of a drop: ufw, provider network firewall, or wrong address. If you understand these two errors correctly, e go save you one hour of guessing, and the difference between connection refused and timed out go help you check the remaining cases.

Turn logging on before the next change

sudo ufw logging on
sudo tail -f /var/log/ufw.log

A blocked packet dey appear like this:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 wey get your own address for SRC= na proof say ufw dey block you, no be the network and no be sshd. For minimal image wey no get rsyslog, /var/log/ufw.log no dey, and na sudo journalctl -k | grep UFW dey produce the same lines. ufw dey rate-limit e own logging rules, so if line no show, e no mean say packet pass.

If you see rules wey you never add

Ruleset wey change by itself no be firewall problem. Person wey get root access write am. Run sudo grep ufw /var/log/auth.log to see which sudo commands run and under which account, then last to check the logins around that time. If the accounts no match anybody wey you know, stop debugging the firewall and work through compromised VPS checklist instead. If you enable firewall again for server wey another person dey control, e go only hide the problem.

Put am back together

Once you don sabi the cause, enable ufw again for a way wey no go repeat the lockout. Allow your actual SSH port, schedule the rollback, enable am, then open a brand-new SSH session from another terminal and confirm say e connect. Na only after that new session don come up you fit close the one wey you dey use. Leave logging on for one day, because the log go show you wetin you forget to allow much faster than reading user.rules go do.

FAQ

ufw disable dey delete my rules?

No. disable dey unload the ruleset from the kernel and write ENABLED=no inside /etc/ufw/ufw.conf. Your rules still dey inside /etc/ufw/user.rules and /etc/ufw/user6.rules, and sudo ufw show added dey list dem while firewall no dey active. Na ufw reset be the command wey dey clear dem, and e first back up each file, then print line like Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Rebooting my VPS go undo ufw lockout?

No. ufw dey start during boot from ENABLED=yes inside /etc/ufw/ufw.conf, so the same rules go load before network come up, and dem go lock you out again. Reboot only go help after you don turn ufw off, or after you edit that file from rescue mode while disk dey mounted. Use provider console and run sudo ufw disable there.

Why Docker container dey reachable when ufw deny the port?

Docker dey write im own DNAT and FORWARD rules for every published port. The traffic dey forward go the container instead of going to the host, so e no ever pass through INPUT chain where your ufw deny rule dey. Publish for loopback with -p 127.0.0.1:5432:5432 when na only host suppose use the port, and inspect wetin Docker install with sudo iptables -t nat -S DOCKER.

I no get console password and no rescue mode. Wetin I fit do?

The options wey remain dey with your provider: password reset from control panel, wey usually reboot the server, or attach the disk to another instance so you fit edit /etc/ufw/ufw.conf from there. Ask support before you rebuild the server, because rebuild dey destroy the data wey dey inside am. Once you don regain access, run sudo passwd yourname and test console login once, so the next lockout no go cost you pass two minutes.