ufw vs firewalld vs nftables: Choosing a Server Firewall

Every Linux server needs a firewall, but the ecosystem offers three different front ends for the same kernel engine, and choosing wrong makes your firewall harder to maintain than to write. Modern kernels filter packets with nftables, while ufw and firewalld are policy layers that generate nftables rules for you. This guide compares the three across the decisions that actually matter — distro fit, rule model, and automation — so you can pick the one that survives first contact with production.

ufw: Simple by Design

ufw is Ubuntu's default firewall front end, and its whole pitch is that a firewall should be expressible in one line. It wraps nftables behind friendly commands, hides the raw rule language, and persists your changes to the running system with no extra ceremony. For a single-interface VPS where the entire policy is "deny everything, allow a few ports," ufw is very nearly the whole answer.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

The deny-incoming, allow-outgoing profile is the correct posture for a public server. ufw orders its rules reading top-down and applies the first match, so put your most specific rules first. Its status output is directly readable by humans and by scripts, which makes it trivially easy to audit what is actually open. The tradeoff: it does not do zones or per-interface policies natively, so if your server has multiple network roles you will outgrow it.

firewalld: Zones and Runtime Semantics

firewalld is the RHEL-family default and is built around zones — named policies assigned to interfaces. Each interface explicitly belongs to a zone, and that zone carries its own allow/deny rules. Its two most important concepts are the permanent store and the runtime view: changes you make --runtime only apply until a reload, while --permanent changes survive it. Getting that distinction wrong is the classic firewalld footgun.

sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-all

Every --permanent flag requires a --reload to move the change into the runtime view, and --list-all tells you what is actually live. The zone model shines when a single box wears multiple hats — a web zone on one interface and a management zone on another — because the policies travel with the interface assignment instead of existing as one flat rule set.

nftables: The Raw Engine

nftables is the modern kernel filtering API that replaced iptables, and both ufw and firewalld quietly compile their rules down to it. Writing nftables directly means owning the syntax: tables to organize, chains to order evaluation, and rules expressed in a native, structured language. It is the most powerful option and the least forgiving, ideal for deterministic, hand-maintained rulesets that must be identical every boot.

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 accept
    tcp dport 80 accept
    tcp dport 443 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
  }
  chain output {
    type filter hook output priority filter; policy accept;
  }
}

The explicit counter of nftables is inconvenient for casual use, but for a security-conscious admin it is liberating: your entire policy lives in a single file you can review in one pass. If you manage many identical servers, an nftables script is a perfect configuration-management asset — one template, applied everywhere.

Which One Fits Your VPS

The deciding factor is usually your distro plus how much automation you run. On Ubuntu or Debian, ufw gives you a safe, auditable default in minutes, and it is what most of the ecosystem's tutorials assume. On Rocky, Alma, or Fedora, firewalld is preinstalled and matches how the packaging and SELinux integration expect you to work. If you manage a fleet with configuration tooling, nftables as a versioned script — or the generated nftables file from either front end — keeps your rules repeatable across every host.

The honest guidance for a single public VPS: use your platform's default front end. The kernel engine is the same underneath all three, and the front end that is preconfigured, pre-documented, and consistent with your package manager will be the one you actually maintain. Only reach for raw nftables when you need fine-grained control that the wrappers hide.

Takeaway

There is no "best" firewall, only the right one for your stack. ufw wins on simplicity for single-role Ubuntu servers, firewalld wins on multi-zone RHEL boxes, and nftables wins when you need deterministic, hand-authored rules. All three filter through the same kernel, so pick the front end your distro and automation already favor. Netbay lets you deploy Ubuntu or Rocky-based VPS plans from the Lucknow DC01 datacenter in under a minute and configure the matching firewall immediately — netbayhosts.in.