How to Regain Access After a UFW/Firewalld SSH Lockout

It is a rite of passage for almost every system administrator. You deploy a brand-new dedicated server, log in via SSH, and decide to follow security best practices by enabling a host-based firewall. You type ufw enable or systemctl start firewalld, press Enter, and suddenly, your terminal freezes.

You try to open a new SSH session, only to be met with a cold, unforgiving error:

ssh: connect to host 192.168.1.50 port 22: Connection refused (or Connection timed out).

A sinking feeling hits your stomach. You are entirely locked out of your SSH dedicated server. Your bare-metal machine is running, the green lights are blinking in the data center, but it is ignoring all your network requests. You have essentially locked the keys inside the car while the engine is still running.

Take a deep breath. Your server is not broken, your data is perfectly safe, and you are not permanently locked out.

This happens because modern firewalls operate on a "Default Deny" policy. If you turn them on without explicitly writing a rule that says "allow my SSH connection," the firewall instantly drops all incoming traffic—including the very SSH session you are using to configure it.

In this comprehensive rescue guide, we will walk you through bypassing your broken network rules using EPY Host's Out-of-Band management (IPMI), logging in locally, executing a UFW connection refused fix, and safely re-enabling your firewall without severing your connection.

What You'll Learn

Phase 1: Understanding the Rescue Method (IPMI)

If the server's operating system is blocking your IP address, how do you get in? You go under the operating system.

When you rent a dedicated server from EPY Host, it comes equipped with IPMI (Intelligent Platform Management Interface) or a BMC (Baseboard Management Controller). This is a tiny, independent computer built directly into the server's motherboard.

IPMI has its own dedicated network port, its own CPU, and its own IP address. Crucially, IPMI does not care about your Linux firewall. Even if your operating system completely shuts down its network interfaces, the IPMI chip remains accessible. By launching the KVM (Keyboard, Video, Mouse) console through IPMI, you are virtually standing inside the data center, plugging a physical monitor and keyboard directly into the back of your server.

Step 1: Access the EPY Host Client Portal

Log in to your EPY Host account and navigate to the Services or Dedicated Servers tab. Select the server you are currently locked out of.

Step 2: Launch the KVM Console

Look for the IPMI, Out-of-Band Management, or KVM Console button. Click to launch the HTML5 or Java-based console.

A new window will open, displaying the physical screen output of your server. If your server has been running for a while, the screen might be black (the monitor is sleeping). Simply press the Enter key or spacebar on your keyboard to wake it up.

Step 3: Log In "Locally"

You should now see the standard Linux login prompt (e.g., ubuntu-server login: or almalinux login:).

Type your root username and press Enter. Then, type your root password. (Note: As a security feature, Linux does not display asterisks or move the cursor when you type a password. Just type it carefully and press Enter).

You now have a root shell. You are inside the machine, completely bypassing the firewall that locked you out.

Phase 2: The UFW Rescue Guide (Ubuntu / Debian)

If you are running Ubuntu or Debian, you are almost certainly dealing with UFW (Uncomplicated Firewall). UFW is designed to be user-friendly, but its default behavior is to deny all incoming connections the moment it is enabled.

1. Step 1: Verify the Lockout

   First, confirm that UFW is actually the culprit. Check its status:

   Bash Copy

   
   ufw status verbose
                                               

   If the output says Status: active and the Default: policy is set to deny (incoming), and you do not see Port 22 listed in the allowed rules, you have found your problem.

2. Step 2: Disable UFW Immediately

   The fastest way to regain SSH access Linux is to simply turn the firewall off. Since you are logged in via the KVM console, you have the authority to do this:

   Bash Copy

   
   ufw disable
                                               

   The console should respond with: Firewall stopped and disabled on system startup.

   Do not close your KVM window yet. Open your normal terminal app on your personal computer (Putty, Terminal, iTerm) and try to SSH into the server again. It should connect instantly.

3. Step 3: Configure UFW the Right Way

   Now that you know how to turn it off, let's turn it back on correctly. We need to tell UFW to explicitly allow SSH traffic before we enable it.

   If your server uses the default SSH port (Port 22), run:

   Bash Copy

   
   ufw allow ssh
                                               

   (Alternatively, you can run ufw allow 22/tcp).

   Crucial Tip for Custom SSH Ports: If you changed your SSH port in /etc/ssh/sshd_config to something like Port 2222 to avoid bots, running ufw allow ssh will not save you. UFW maps "ssh" to port 22. You must explicitly allow your custom port:

   Bash Copy

   
   ufw allow 2222/tcp
                                               

4. Step 4: Whitelist Your Static IP (Advanced Security)

   If you want to be incredibly secure, you shouldn't open SSH to the entire internet. You should only allow SSH connections from your specific office or home IP address.

   First, find your personal public IP address (you can google "What is my IP" on your local computer). Let's assume your IP is 203.0.113.50.

   Run this command to whitelist your IP for SSH:

   Bash Copy

   
   ufw allow from 203.0.113.50 to any port 22
                                               

5. Step 5: Safely Re-Enable UFW

   Now that the rules are in place, you can safely turn the firewall back on:

   Bash Copy

   
   ufw enable
                                               

   UFW will warn you: Command may disrupt existing ssh connections. Proceed with operation (y|n)?. Type y and press Enter.

   Because you explicitly allowed Port 22 in Step 3, your SSH connection will not drop this time.

Phase 3: The Firewalld Rescue Guide (AlmaLinux / RHEL / CentOS)

If you are running an Enterprise Linux distribution, your server uses Firewalld. Unlike UFW, Firewalld uses the concept of "Zones" to manage trust levels. By default, most network interfaces are assigned to the public zone, which drops unauthorized traffic.

1. Step 1: Verify the Lockout

   Check if Firewalld is running and actively blocking you:

   Bash Copy

   
   firewall-cmd --state
                                               

   If it returns running, check what services are currently allowed in your active zone:

   Bash Copy

   
   firewall-cmd --list-all
                                               

   Look at the services: line. If ssh is missing from that list, Firewalld is dropping your connection.

2. Step 2: Stop Firewalld

   Let's stop the service so you can regain normal network access.

   Bash Copy

   
   systemctl stop firewalld
                                               

   Test your SSH connection from your local computer. It should now work perfectly.

3. Step 3: Configure Firewalld the Right Way

   We need to permanently add the SSH service to your public zone.

   Start the firewall again so we can configure it (don't worry if it kicks your SSH session, you are still logged into the KVM console):

   Bash Copy

   
   systemctl start firewalld
                                               

   Now, add the SSH rule permanently:

   Bash Copy

   
   firewall-cmd --permanent --zone=public --add-service=ssh
                                               

   If you use a custom SSH port (e.g., 2222), you cannot use the --add-service flag because Firewalld defines the SSH service strictly as port 22. Instead, you must add the port manually:

   Bash Copy

   
   firewall-cmd --permanent --zone=public --add-port=2222/tcp
                                               

4. Step 4: Whitelist Your Static IP (Rich Rules)

   If you want to restrict SSH access exclusively to your own IP address (e.g., 203.0.113.50), Firewalld uses "Rich Rules" to handle complex logic.

   Run this command to create a rich rule that accepts SSH traffic only from your IP:

   Bash Copy

   
   firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.50" port protocol="tcp" port="22" accept'
                                               

5. Step 5: Reload to Apply Changes

   Firewalld requires you to reload its configuration for --permanent rules to take effect in the live runtime environment.

   Bash Copy

   
   firewall-cmd --reload
                                               

   Try connecting via SSH from your local machine. You should now be securely connected with the firewall actively protecting the rest of your server.

Phase 4: The Nuclear Option (Flushing Raw iptables)

Sometimes, server administrators try to get clever. They install UFW, then they install Fail2Ban, then they install a custom control panel (like cPanel or Plesk), and suddenly they have three different programs writing conflicting firewall rules.

If disabling UFW or stopping Firewalld doesn't work, it means there are raw iptables or nftables rules deeply embedded in the kernel network stack that are actively rejecting your packets. To fix a Firewalld flush rules IPMI failure, we must drop a nuclear bomb on the firewall table.

1. Step 1: View the Damage

   To see the raw rules currently active in the Linux kernel, run:

   Bash Copy

   
   iptables -L -n -v
                                               

   If you see hundreds of lines of complex routing chains, your firewall is heavily entangled.

2. Step 2: Flush the Rules

   Execute the following three commands in exact order. This will delete every single firewall rule, delete every custom chain, and reset the default policy to ALLOW.

   Warning: If your server relies on complex NAT routing for virtual machines, this will break their internet access until you reboot or reload those specific configurations. However, it guarantees you will get your SSH access back.

   Bash Copy

   
   # 1. Set the default policies to ACCEPT
   iptables -P INPUT ACCEPT
   iptables -P FORWARD ACCEPT
   iptables -P OUTPUT ACCEPT
   
   # 2. Flush all existing rules
   iptables -F
   
   # 3. Delete all custom chains
   iptables -X
                                               

   After running these commands, run iptables -L -n -v again. The output should be nearly empty, showing only the three default chains set to ACCEPT. Your server is now completely wide open to the internet.

   Log in via SSH, uninstall the conflicting firewall managers, pick one (either UFW or Firewalld), and configure it properly from scratch.

The Golden Rule of Remote Firewalls

Being locked out of a server is a stressful, heart-stopping moment, but it is an entirely avoidable mistake.

To prevent this from ever happening again, you must memorize the Golden Rule of Remote Firewalls:

Never enable or restart a firewall without having an active, secondary SSH session open.

When you are configuring UFW or Firewalld via SSH, your current active connection is often preserved by the kernel's stateful packet inspection (it knows the connection was already established). The true test is whether a new connection can be made.

• Before you type exit and close your terminal, always open a second terminal window on your laptop and attempt to establish a brand-new SSH connection to the server.

• If the second window connects successfully, your firewall rules are correct, and you can safely close your session.

• If the second window hangs or says "Connection Refused," your rules are broken. But because your first window is still connected, you can easily type ufw disable or fix the typo without having to resort to the IPMI console.

Conclusion

A "Connection Refused" error immediately after configuring a firewall is not a server failure; it is the firewall doing exactly what you told it to do—block unknown traffic. By understanding how to leverage your EPY Host IPMI KVM console, you can easily bypass the network stack, drop into a local root shell, and correct your configuration files.

Whether you prefer the simplicity of UFW on Ubuntu or the robust zone-based architecture of Firewalld on AlmaLinux, always ensure that Port 22 (or your custom SSH port) is explicitly allowed before flipping the switch.