Firewalld on AlmaLinux: A VPS Firewall Setup Guide

If you followed a UFW tutorial on your AlmaLinux VPS and got "command not found," you haven't broken anything - UFW just isn't part of the RHEL family. AlmaLinux, CentOS, and Rocky Linux ship with firewalld instead, and it's built around a different model (zones, not a simple allow-list), so copy-pasting Ubuntu commands won't get you anywhere. Here's how firewalld actually works and how to lock down a fresh AlmaLinux VPS without locking yourself out of it.

Symptom: no firewall active, or your UFW commands do nothing

A few ways this shows up on an AlmaLinux, CentOS, or Rocky Linux VPS:

• sudo ufw enable returns "command not found," or installing UFW manually behaves strangely alongside the system's own firewall.
• firewall-cmd --state comes back "not running," and ss -tulpn shows MySQL, Redis, or an app server listening on 0.0.0.0 for anyone to reach.
• You opened a port with firewall-cmd --add-port, it worked, then vanished after a reboot or a config reload.
• An app or API integration can't reach a service that's clearly running, even though nothing in the app changed.

All four trace back to the same thing: firewalld manages zones and rule permanence very differently from UFW, and most tutorials online are written for Ubuntu.

Cause: AlmaLinux uses firewalld, not UFW

UFW is a friendly wrapper around iptables/nftables built for Debian and Ubuntu. AlmaLinux and the rest of the RHEL family use firewalld, a separate service that also sits on top of nftables but organizes rules into named zones instead of one flat allow/deny list. Get the zone concept wrong and your rules can be perfectly correct but simply not applied to the interface that matters.

Check what's actually running before you change anything

systemctl status firewalld
firewall-cmd --state

If it's not installed at all (rare on a stock AlmaLinux image, but happens on minimal builds):

sudo dnf install firewalld
sudo systemctl enable --now firewalld

Zones: the part that trips people up

A zone is a named set of rules applied to a network interface. Every AlmaLinux VPS interface gets assigned to a zone - almost always public by default - and any rule you add only takes effect if it's added to the zone your interface is actually in.

firewall-cmd --get-default-zone
firewall-cmd --get-active-zones

The second command shows you which zone is bound to which interface (usually eth0 on a VPS). If you edit the public zone but your interface is somehow bound to a different one, none of your changes will do anything - and that mismatch is one of the most common "I added the rule but it's still not working" tickets we see.

Fix: set up firewalld on a fresh VPS

1. Confirm SSH won't get cut off

Check what's already allowed before you touch defaults - firewalld's public zone usually permits ssh out of the box, but confirm it rather than assume:

firewall-cmd --list-all

If you've moved SSH to a non-standard port, add it explicitly before doing anything else:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

2. Allow only what your app needs

For a typical web server:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

firewalld ships with named services for common software (http, https, mysql, smtp) so you rarely need to remember raw port numbers. List them all with firewall-cmd --get-services if you're not sure a service you need already has a name.

3. Remove what you don't need

Minimal AlmaLinux images sometimes ship with extras like cockpit or dhcpv6-client pre-allowed. Strip anything you're not using:

sudo firewall-cmd --permanent --remove-service=cockpit
sudo firewall-cmd --reload

4. Restrict sensitive ports to specific IPs with rich rules

For something like a database or phpMyAdmin that only your office or home IP should reach, a plain port rule opens it to the world. Use a rich rule to scope it:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port protocol="tcp" port="3306" accept'
sudo firewall-cmd --reload

Better still for anything that doesn't need to be public at all - MySQL, Redis, an admin dashboard - bind the service itself to 127.0.0.1 in its own config so there's nothing to firewall in the first place.

5. Verify before you close your session

firewall-cmd --list-all

Open a second terminal and start a fresh SSH connection before you close your current one. If the new connection fails, your existing session is still open to fix it.

The --permanent trap

This is the single most common firewalld mistake. firewall-cmd --add-port=8080/tcp without --permanent only changes the running configuration - it works immediately, which is exactly why people stop there. The next reboot, or the next firewall-cmd --reload, wipes it out and the rule is just gone. Always pair a rule with --permanent, then apply it with a separate --reload:

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

If you want to test a rule live before committing to it, add it without --permanent first, confirm it works, then re-run the same command with --permanent added and reload.

Running cPanel/WHM on AlmaLinux? Don't run firewalld alongside CSF

If this VPS also runs cPanel/WHM, don't manage both firewalld and ConfigServer Security & Firewall (CSF) at once - they'll fight over the same iptables/nftables rules and produce exactly the kind of contradictory lockout that's miserable to debug at 2 a.m. WHM's own firewall stack expects to own that layer; disable firewalld and let CSF handle it instead:

sudo systemctl stop firewalld
sudo systemctl disable firewalld

See our CSF setup guide for the WHM-specific steps once firewalld is out of the way.

Already locked yourself out?

If a reload or a bad rule just cut your SSH session, don't panic and don't reboot repeatedly hoping it clears - reboots don't reset firewalld rules that were saved with --permanent. Instead:

1. Open your VPS provider's browser-based console/VNC (in the Getwebup panel, this is available even with no network access).
2. Log in locally through the console and re-check your rules: firewall-cmd --list-all.
3. Re-add the SSH port and reload: firewall-cmd --permanent --add-service=ssh && firewall-cmd --reload.
4. If you're not sure what broke it, temporarily stop firewalld from the console (systemctl stop firewalld), get back in over SSH, then rebuild your rules calmly instead of guessing blind.

firewalld vs UFW vs raw iptables

Prevention

• Always keep a second terminal open before enabling or reloading firewalld on a server you're only reachable through via SSH.
• Pair every rule change with --permanent, then --reload - never leave a rule as runtime-only and assume it'll survive.
• Check firewall-cmd --get-active-zones after any change to confirm your interface is actually in the zone you just edited.
• Bind services that don't need to be public to 127.0.0.1 instead of opening and then restricting a firewall port for them.
• If you later add cPanel/WHM to this server, disable firewalld and hand the job to CSF rather than running both.