How to Install Firewalld on Debian 13, 12 and 11

Fresh Debian installs leave host firewall policy to the administrator, so the first time you expose SSH, a web server, or another network service, you need to choose how you want to manage local filtering. When you install Firewalld on Debian, you get zone-based rules, service-aware commands, and live changes through firewall-cmd without restarting the daemon.

Firewalld is not installed by default on Debian 13 (Trixie), Debian 12 (Bookworm), or Debian 11 (Bullseye), but the APT workflow stays the same once you choose it as your firewall manager. The same workflow also answers the first-use questions Debian users usually hit right away, including the default public zone, the built-in ssh allowance, and when a rule needs --permanent plus a reload.

Install Firewalld on Debian

The installation path stays the same across Debian 13, 12, and 11. Only the packaged Firewalld branch changes by release.

Debian release	Codename	Packaged Firewalld branch
Debian 13	Trixie	2.3.x
Debian 12	Bookworm	1.3.x
Debian 11	Bullseye	0.9.x

Update Debian Before Installing Firewalld

Refresh the APT package index first so Debian pulls the current Firewalld package for your release.

sudo apt update

These commands use sudo for package management and firewall changes. If your account does not have sudo access yet, add a user to sudoers on Debian first.

Install the Firewalld Package on Debian

Install Firewalld from Debian’s default repositories.

sudo apt install firewalld -y

The -y flag accepts the package prompt automatically, which is convenient when you already know you want the Debian package.

Relevant output includes:

Setting up firewalld (2.3.1-1+deb13u1) ...
Created symlink '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service' -> '/usr/lib/systemd/system/firewalld.service'.
Created symlink '/etc/systemd/system/multi-user.target.wants/firewalld.service' -> '/usr/lib/systemd/system/firewalld.service'.

On Debian 13, 12, and 11, the package enables and starts firewalld.service during installation. You do not need a separate systemctl enable --now firewalld step in the main install flow.

Verify the Firewalld Command and Service on Debian

Confirm that the command exists, the package reports a version, and the daemon is already running.

command -v firewall-cmd
sudo firewall-cmd --version
systemctl is-enabled firewalld
sudo firewall-cmd --state

Expected output on Debian 13 includes:

/usr/bin/firewall-cmd
2.3.1
enabled
running

The exact package revision depends on the Debian release. Current package metadata shows 2.3.1-1+deb13u1 on Debian 13, 1.3.3-1~deb12u1 on Debian 12, and 0.9.3-2+deb11u1 on Debian 11.

If you run firewall-cmd without sudo over SSH, Debian can return a polkit authorization error even though Firewalld is installed correctly. Use sudo for rule changes and daemon checks in remote shells.

Get Started With Firewalld on Debian

Firewalld feels different if you are coming from UFW or direct nftables rules on Debian. The mental model is simpler once you separate where a rule lives, what traffic it permits, and whether that change is only for the current session or saved for the next reboot.

Understand Firewalld Terms on Debian

Before you open ports or services, get comfortable with the five ideas that shape almost every Firewalld command on Debian:

• Zone: A trust profile that groups interfaces and rules together. On Debian 13, Debian 12, and Debian 11, Firewalld starts in the public zone after installation.
• Service: A named rule set such as ssh, http, or https that opens the expected ports and protocols for that workload.
• Port rule: A direct PORT/protocol rule for custom daemons, lab services, or software that does not have a built-in Firewalld service definition.
• Runtime configuration: A live change that takes effect immediately but disappears after a reboot or Firewalld restart if you never save it.
• Permanent configuration: A saved rule set under /etc/firewalld that survives reboots after you reload the daemon.

If you are used to UFW, the closest translation is that zones decide where a rule lives, while services and ports decide what that zone allows. Firewalld writes the lower-level firewall rules for you, so day-to-day administration stays at the firewall-cmd layer instead of raw backend syntax.

For a broader command reference after the package is installed, use firewall-cmd command examples alongside the Debian-specific service and package notes here.

Compare Firewalld and UFW on Debian

Choose Firewalld when zones, runtime testing, permanent rule sets, and service definitions fit the way you manage a server. Choose UFW when you want a smaller command set for simple allow and deny rules. Avoid running both as active firewall managers on the same host unless you intentionally audit both rule sets, because overlapping tools can make the effective policy harder to reason about.

If UFW is the better match for the system, install UFW on Debian instead of configuring both managers for the same access policy.

Check Active Firewalld Zones and Rules on Debian

Review the active zone and the rules already applied before you start opening services or ports.

FW_ZONE=$(sudo firewall-cmd --get-default-zone)
printf '%s\n' "$FW_ZONE"
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone="$FW_ZONE" --list-all

Relevant output includes:

public
public (default)
  interfaces: ens33

public (default, active)
  target: default
  services: dhcpv6-client ssh
  ports:
  rich rules:

After installation on Debian 13, 12, and 11, Firewalld starts with the public zone active and ssh already allowed in that zone. That default helps preserve remote access, but you should still confirm the active zone before you add web, database, or custom application rules.

If ssh is missing because you already changed zones or trimmed service rules, restore it before you close the terminal session. If OpenSSH is not installed yet, install SSH on Debian before you lock down remote access.

Choose Service Rules or Port Rules on Debian

A lot of early Firewalld confusion comes from treating services and ports as interchangeable. Both open traffic, but they solve different problems and are easier to maintain when you choose the right one from the start.

When you need to	Prefer	Why it fits better
Expose a standard daemon such as SSH or a web server	--add-service=ssh, --add-service=http, or --add-service=https	Built-in service definitions stay readable and cover the expected ports and protocols.
Expose a custom listener such as 8080/tcp	--add-port=8080/tcp	Direct port rules are better when no service definition matches the application.
Test a temporary change	Add the rule without --permanent, then query it	Runtime rules let you confirm the service still works before you decide what belongs after reboot.
Write the final rule to disk immediately	Add --permanent and then reload	This is the cleaner path when you already know the rule belongs in the long-term policy.

For standard network services, prefer service definitions because future reviews stay easier to read and audit. Reach for raw ports when the application is custom, temporary, or built around a non-standard listener.

Manage Firewalld Rules on Debian

Firewalld keeps runtime rules separate from permanent rules. On Debian servers, the safer habit is to add one rule, confirm the active zone still looks right, and only then save the rules you want after the next reboot.

Use the same zone variable for add, query, remove, and reload commands so each rule change stays aligned with the zone you inspected. On a fresh Debian install this usually prints public; if your active interface belongs to another zone, set FW_ZONE to that zone instead. Run the variable command again in any new shell before using the rule examples.

FW_ZONE=$(sudo firewall-cmd --get-default-zone)
printf '%s\n' "$FW_ZONE"

Expected output on a clean Debian Firewalld install is:

public

Allow a Service With Firewalld on Debian

Allow the built-in HTTP service definition through the selected zone and confirm that the rule was saved. Open the firewall only after the web server itself is installed and listening; a Firewalld rule does not start the daemon behind that port.

sudo firewall-cmd --zone="$FW_ZONE" --add-service=http --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone="$FW_ZONE" --query-service=http

Expected output on Debian 13 includes:

success
success
yes

Use the same pattern for other built-in service definitions such as https, dns, or smtp. For the full service and zone reference, the official Firewalld documentation is the best reference.

Open a Port With Firewalld on Debian

Open a raw TCP port when no built-in service definition matches the application you are exposing.

sudo firewall-cmd --zone="$FW_ZONE" --add-port=8080/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone="$FW_ZONE" --query-port=8080/tcp

Expected output:

success
success
yes

When you want to close the same port later, switch --add-port=8080/tcp to --remove-port=8080/tcp and reload again.

Remove a Firewalld Rule on Debian

Cleaning up old rules matters just as much as opening new ones. Remove the unused service or port, reload the saved configuration, and confirm the rule disappeared from the active zone.

sudo firewall-cmd --zone="$FW_ZONE" --remove-service=http --permanent
sudo firewall-cmd --zone="$FW_ZONE" --remove-port=8080/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone="$FW_ZONE" --list-all

Relevant output includes:

success
success
success
services: dhcpv6-client ssh
ports:

If you only need to undo one of those examples, remove the matching command for the rule you are keeping. Firewalld tracks services and raw ports separately, so deleting one does not automatically delete the other.

Save Runtime Firewalld Rules Carefully on Debian

If a rule works immediately but disappears after a reboot, you only changed the runtime configuration. Review the current runtime rules before copying them into permanent storage, because --runtime-to-permanent saves the whole active runtime state, not only the last rule you tested.

sudo firewall-cmd --zone="$FW_ZONE" --list-services
sudo firewall-cmd --zone="$FW_ZONE" --list-ports

If the runtime services and ports are the rules you want after reboot, save them and reload Firewalld.

sudo firewall-cmd --runtime-to-permanent
sudo firewall-cmd --reload

Expected output:

success
success

For new rules that you already know should persist, prefer adding --permanent when you create the rule, then reload and query that specific service or port.

Troubleshoot Firewalld on Debian

The most common Firewalld problems on Debian are a missing package, an unprivileged shell, or temporary runtime rules that were never saved. Start with the exact symptom instead of changing random rules.

Fix the firewall-cmd Command Not Found Error on Debian

If Debian cannot find firewall-cmd, the Firewalld package is not installed or the binary is no longer present.

command -v firewall-cmd || echo firewall-cmd-not-found
dpkg -l firewalld | grep '^ii' || echo firewalld-not-installed

Expected output when the package is missing:

firewall-cmd-not-found
firewalld-not-installed

Install Firewalld with sudo apt install firewalld -y, then rerun the verification commands from the install section.

Fix Firewalld Authorization Errors on Debian

If you run Firewalld from an SSH session without sudo, Debian can reject the request before the command reaches the daemon.

For example, this unprivileged check can fail in an SSH session:

firewall-cmd --state

A typical error looks like this:

Authorization failed.
    Make sure polkit agent is running or run the application as superuser.

This happens because the shell session does not have a polkit agent available to approve the action. Rerun the command with sudo instead of trying to manage Firewalld as an unprivileged user.

sudo firewall-cmd --state

Expected output:

running

Update, Disable, or Remove Firewalld on Debian

Firewalld comes from Debian’s default APT repositories in this workflow, so package updates, service control, and removal stay inside normal Debian package management.

Update Firewalld on Debian

Update Firewalld alongside system packages from enabled APT sources. The Debian package installed earlier comes from Debian’s default repository, so normal package upgrades keep it current within that release. Use apt upgrade for normal package updates, review the package list before confirming, and reserve release upgrades for Debian release-migration workflows.

sudo apt update
sudo apt upgrade

If APT updates the Firewalld package while the service is running, check the daemon state afterward before changing rules.

sudo firewall-cmd --state

Expected output:

running

Stop here if you only need to disable the firewall temporarily for testing. Remove the package only when you are switching to another firewall manager or no longer want Firewalld on the system.

Disable Firewalld on Debian Without Uninstalling It

Disable the service and stop it immediately when you want to keep the package installed but take the firewall offline.

sudo systemctl disable --now firewalld
systemctl is-enabled firewalld
systemctl is-active firewalld

Relevant status output after the disable command includes:

disabled
inactive

Bring the service back with the same package and saved rules still in place:

sudo systemctl enable --now firewalld

Confirm that Firewalld is enabled again before you move on.

systemctl is-enabled firewalld
sudo firewall-cmd --state

Relevant status output after re-enabling Firewalld includes:

enabled
running

Remove the Firewalld Package on Debian

Removing Firewalld leaves Debian without this firewall manager. If you still want an actively managed firewall afterward, install UFW on Debian before you make the host internet-facing again.

Purge the package when you want to remove the Firewalld binary and its packaged conffiles.

sudo apt purge firewalld

After that, Debian can also offer an optional dependency cleanup:

sudo apt autoremove

Review the apt autoremove package list before you confirm it. On long-lived Debian systems, APT can include unrelated auto-installed packages such as older kernel images in that cleanup list.

Confirm that Debian no longer sees the command as installed.

dpkg -l firewalld | grep '^ii' || echo firewalld-not-installed

Expected output:

firewalld-not-installed

If you previously saved permanent rules, zone files, or policies, check whether anything remains under /etc/firewalld before you delete that directory manually. On Debian 13, Debian 12, and Debian 11, a purge after permanent rule changes can still leave saved XML files behind.

sudo find /etc/firewalld -maxdepth 2 -type f

Relevant output includes:

/etc/firewalld/zones/public.xml
/etc/firewalld/zones/public.xml.old

Delete /etc/firewalld only if that find command still prints saved zone or policy files you no longer want. Removing the directory permanently deletes your custom Firewalld configuration.

sudo rm -rf /etc/firewalld

Conclusion

Firewalld is now installed on Debian with a working zone-based firewall workflow, so you can review services, open only the ports you need, and keep those changes across reboots when they are ready. If remote administration is next, install SSH on Debian. For automatic brute-force bans on internet-facing services, install Fail2Ban on Debian.