How to Install Firewalld on Fedora Linux

When you install Firewalld on Fedora Linux, you gain a dynamic firewall manager that protects your system from network threats while giving you precise control over incoming and outgoing traffic. Unlike static firewalls that require a full restart for every change, Firewalld lets you adjust rules on the fly without interrupting active connections.

This guide shows you how to verify the installation, enable the daemon, manage zones and services, implement advanced policies, and troubleshoot the issues that appear on Fedora desktops and servers.

What Is Firewalld?

Think of Firewalld as a security guard for your network connections. It sits between your Fedora system and the internet, deciding which traffic gets through and which gets blocked. Instead of managing individual iptables rules manually, Firewalld provides a friendlier command-line interface and organizes rules into zones based on trust levels.

Firewalld ships pre-installed on Fedora Workstation and most desktop installations. If you run Fedora Server, a minimal cloud image, or a container-based deployment, you may need to install it manually. Firewalld offers several key capabilities:

• Dynamic Management: Firewalld allows users to make real-time changes to the firewall settings without restarting the service.
• Zone-based Management: Users can group network interfaces into different zones, each with specific firewall rules, allowing for varied levels of trust.
• Rich Language Rules: This feature offers detailed control over firewall settings, accommodating complex rules and exceptions for different networking needs.
• Service-specific Configurations: Firewalld lets users set specific firewall rules for individual services or applications, adding another layer of customization.
• IPv6 Support: With compatibility for IPv6, Firewalld ensures your system remains secure as the internet transitions to the next generation of IP addresses.

On desktop systems, Firewalld controls incoming and outgoing traffic for safer browsing and reduced malware risk. For servers exposed to the internet, Firewalld’s zone-based management and service-specific configurations become essential for blocking unauthorized access while keeping legitimate services running. Whether you’re securing a development workstation or hardening a production server, Firewalld gives you the flexibility to adapt firewall rules to different network environments without compromising uptime. If you prefer a graphical interface, see our guide on installing the Firewalld GUI on Fedora.

Check If Firewalld Is Installed

Before installing Firewalld, verify whether it already exists on your system. Most Fedora installations include Firewalld by default, so checking first avoids unnecessary reinstallation. Run the following command to check the installed version:

Open a terminal by searching for “Terminal” in Activities or by clicking the terminal icon in your dock. The commands in this guide use sudo to grant temporary administrator privileges, and DNF handles package downloads from Fedora’s repositories.

sudo firewall-cmd --version

If Firewalld is installed, you’ll see output showing the version number:

2.3.2

If Firewalld is absent, you’ll see an error message like “command not found,” indicating you need to install it using the steps below.

Install Firewalld on Fedora

If Firewalld isn’t on your system, install it using the DNF package manager. Execute this command:

sudo dnf install firewalld

DNF downloads the package from Fedora’s repositories along with any required dependencies, then installs everything automatically. The installation typically completes in under a minute on modern systems.

Enable and Start Firewalld

After installation, configure Firewalld to start automatically at boot and bring it online immediately. The systemctl command handles both tasks in a single step:

sudo systemctl enable --now firewalld

The --now flag starts Firewalld immediately while also creating the boot-time symlink. You should see confirmation that the service is enabled and running.

Verify Firewalld Status

Confirm that Firewalld is running correctly by checking its service status. This verification step ensures the installation and enablement succeeded before you start configuring rules:

sudo systemctl status firewalld

Look for “active (running)” in the output, which confirms the service is operational:

● firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-01-08 06:15:32 UTC; 2min ago
       Docs: man:firewalld(1)
   Main PID: 1234 (firewalld)
      Tasks: 2 (limit: 4652)
     Memory: 32.4M
        CPU: 312ms
     CGroup: /system.slice/firewalld.service
             └─1234 /usr/bin/python3 -sP /usr/sbin/firewalld --nofork --nopid

If you see “inactive (dead)” or any errors, revisit the installation and enablement steps. For a quick state check without the full output, run sudo firewall-cmd --state, which returns simply running if the daemon is active.

Firewalld Command Basics

Before diving into specific firewall rules, understanding how Firewalld commands work helps you avoid mistakes and build confidence. The firewall-cmd tool follows a consistent pattern that becomes intuitive once you grasp the basics.

Firewalld requires administrative privileges on Fedora. All examples use sudo; drop it only if you are already working inside a root shell or have custom polkit rules.

Firewalld Command Syntax

Every Firewalld command follows this structure:

firewall-cmd [options] command

Breaking down each component:

• firewall-cmd: The command-line client that communicates with the Firewalld daemon
• options: Modifiers that control where and how changes apply:
• --zone=name targets a specific firewall zone instead of the default
• --permanent saves changes to configuration files so they survive reboots
• --reload applies permanent changes immediately without dropping connections
• command: The action to perform, such as --add-service, --list-all, or --add-port

Use the quick-reference table below to see how the most important firewall-cmd options map to real-world administration tasks.

Identify the default zone: Shows which zone handles new interfaces so you know where rules land by default.

sudo firewall-cmd --get-default-zone

Target a specific zone: Add the --zone=name option to scope the command to that zone instead of the default.

sudo firewall-cmd --zone=public --list-all

Make a change persistent: Append --permanent and reload so the rule survives reboots.

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

Test a change temporarily: Skip --permanent so the rule only affects the runtime configuration.

sudo firewall-cmd --add-service=http

Save all runtime rules: Copy the current runtime configuration into permanent storage in one step.

sudo firewall-cmd --runtime-to-permanent

Temporary vs Permanent Rules

By default, Firewalld changes take effect immediately but disappear after a reboot. To make rules permanent, add the --permanent flag to your command, then run sudo firewall-cmd --reload to apply them to the running configuration. This two-step approach lets you test rules safely before committing them.

At its simplest, checking your active firewall zone requires just:

sudo firewall-cmd --get-default-zone

This returns the name of your default zone (typically “public” on fresh installations) without making any changes. Once you understand this foundation, the following commands follow the same logical pattern.

Basic Firewalld Commands

The following commands cover the most common Firewalld tasks you’ll use regularly. Each example shows the exact syntax you need, along with context for when you’d use it in real scenarios.

How Firewalld Zones Work

Firewalld organizes network interfaces into zones, each representing a different trust level. For example, your home network might use the “home” zone with relaxed rules, while a public Wi-Fi connection uses the stricter “public” zone. Network interfaces automatically get assigned to zones based on your configuration, letting you apply different security policies to different connections simultaneously.

Display All Zones

View all available zones and their complete configurations with this command:

sudo firewall-cmd --list-all-zones

The output displays every zone (public, home, work, etc.) along with their allowed services, ports, and interfaces. This comprehensive view helps when diagnosing connectivity issues or planning zone assignments.

Get the Default Zone

Check which zone handles network traffic by default:

sudo firewall-cmd --get-default-zone

public

The output returns a single word indicating which zone applies to new network interfaces automatically. Firewalld’s base default is public. However, Fedora provides two additional zone definitions: FedoraWorkstation (opens high ports for desktop use) and FedoraServer (includes the Cockpit web console). The default zone may vary depending on how your system was installed or configured.

Set a Default Zone

Change the default zone to match your environment’s trust level. For example, to set the home zone as default for a workstation on a trusted network:

sudo firewall-cmd --set-default-zone=home

The home zone enables more permissive rules suitable for trusted local networks. On servers or public-facing systems, stick with the “public” zone for tighter security.

List Services in a Zone

See which services are allowed through a specific zone’s firewall. To inspect the public zone:

sudo firewall-cmd --zone=public --list-services

dhcpv6-client mdns ssh

The output shows service names that are currently permitted through that zone. If you’re troubleshooting why a service isn’t accessible, this command quickly reveals whether you’ve allowed it through the firewall.

Add a Service to a Zone

Allow a service through the firewall by adding it to a zone. For example, to allow HTTP traffic through the public zone:

sudo firewall-cmd --zone=public --add-service=http

If you’re setting up an Apache web server on Fedora, you’ll typically add both HTTP and HTTPS services. Remember to add --permanent and reload for the change to persist across reboots.

Remove a Service from a Zone

Block a service by removing it from a zone’s allowed list. For example, to remove the mDNS discovery service from the public zone:

sudo firewall-cmd --zone=public --remove-service=mdns

This immediately blocks the service in the running configuration. Add --permanent and reload if you want the block to survive reboots.

Reload Firewalld Configuration

Apply permanent configuration changes without dropping existing connections:

sudo firewall-cmd --reload

Unlike restarting the firewall service, reloading preserves active network connections while loading updated rules from disk. This is critical for production servers where you can’t afford dropped SSH sessions.

List All Rules in a Zone

Get a complete overview of everything configured in a zone, including services, ports, rich rules, and more. For example, to inspect the public zone:

sudo firewall-cmd --zone=public --list-all

This comprehensive output displays the zone’s target policy, interfaces, allowed services, open ports, and any advanced rich rules. It’s your go-to command for auditing zone configurations.

Add a Port to a Zone

Open a specific port for traffic when no predefined service exists for your application. For example, to allow TCP traffic on port 8080 for a custom web application:

sudo firewall-cmd --zone=public --add-port=8080/tcp

Always specify either tcp or udp based on your application’s requirements. Add --permanent and reload to make the rule persistent.

Remove a Port from a Zone

Close a previously opened port when you no longer need it. For example, to close the 8080/tcp port opened earlier:

sudo firewall-cmd --zone=public --remove-port=8080/tcp

This closes the port immediately in the running config. Add --permanent and reload to make the closure permanent across reboots.

Firewall Zones Reference Guide

Firewalld organizes network security into nine predefined zones, each representing a different trust level. Understanding which zone fits your network environment helps you apply appropriate security policies without over-restricting legitimate traffic or leaving vulnerabilities open.

Zone Comparison Table

Zones range from “drop” (zero trust, maximum security) to “trusted” (full trust, no restrictions). Use this table to quickly identify which zone matches your network environment:

Zone	Trust Level	Default Behavior	Best For
drop	Zero	Silently drops all incoming packets; only outgoing works	Hostile Wi-Fi (airports, hotels)
block	Zero	Rejects with ICMP messages instead of silent drop	Untrusted networks requiring RFC compliance
public	Low	Only explicitly enabled services; SSH and DHCP allowed by default	Cloud servers, coffee shops, untrusted networks
external	Low	Masquerading (NAT) enabled for routing between networks	Fedora as router, VPN gateway, network appliance
dmz	Low	Selected services only; isolated from internal infrastructure	Public-facing web servers, mail servers
work	Medium	Trusts coworkers; file sharing and printers accessible	Corporate office networks
home	Medium	Relaxed rules; mDNS, Samba, DHCP client allowed	Home networks with family devices
internal	High	Similar to home but for business networks	Server-to-server, backup networks, management interfaces
trusted	Full	Accepts all traffic; firewall effectively disabled	VPN tunnels, WireGuard interfaces, encrypted links

Fedora-Specific Zones

In addition to the nine standard zones, Fedora includes two distribution-specific zones:

• FedoraWorkstation: Opens ports 1025-65535 for desktop applications, making it more permissive than public while still blocking privileged ports
• FedoraServer: Similar to public but includes the Cockpit web console service by default for server management

Choosing the Right Zone

When deciding which zone to use, consider three factors: the network’s trust level, the services you need to expose, and the consequences of a breach. A laptop moving between coffee shop Wi-Fi (public zone) and home network (home zone) should switch zones accordingly. Servers typically stay in one zone (public for most cloud servers, DMZ for web servers, internal for databases) based on their role. Assign interfaces to zones that match the network environment, not the hardware’s physical location.

Advanced Firewalld Configuration

Beyond basic service and port management, Firewalld supports advanced scenarios like custom zones, IP blocking, and rich rules. These capabilities become essential when securing production servers or managing complex network environments.

Create Custom Services for Reusable Rules

When you need to expose the same application across multiple zones or hosts, create a custom service definition instead of juggling raw port numbers. Service XML files live under /etc/firewalld/services/ and persist across package updates.

sudo tee /etc/firewalld/services/nodeapp.xml <<'EOF'
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>nodeapp</short>
  <description>Node.js dashboard on TCP port 3000</description>
  <port protocol="tcp" port="3000"/>
</service>
EOF
sudo firewall-cmd --permanent --add-service=nodeapp --zone=public
sudo firewall-cmd --reload

Edit the XML to match your application name, description, and port list. Once loaded, you can grant the service to any zone with --add-service=nodeapp just like the built-in definitions.

Creating Custom Zones for Specific Networks

Custom zones let you apply different security policies to different network segments. For example, you might create a “webservers” zone for public-facing servers with only HTTP and HTTPS allowed. After creating a zone, assign services and move the relevant network interface into it:

sudo firewall-cmd --permanent --new-zone=webservers
sudo firewall-cmd --permanent --zone=webservers --add-service=http
sudo firewall-cmd --permanent --zone=webservers --add-service=https
sudo firewall-cmd --permanent --zone=webservers --add-interface=eth1
sudo firewall-cmd --reload

Repeat the --add-service command for each protocol you want to allow through this zone. Use --add-interface to assign the corresponding network interface to your new zone.

Deleting Unused Zones

Remove custom zones you no longer need to keep your configuration clean. For example, to delete the webservers zone created earlier:

sudo firewall-cmd --permanent --delete-zone=webservers
sudo firewall-cmd --reload

You cannot delete built-in zones like “public” or “home,” only custom zones you’ve created. Before deleting a zone, ensure no interfaces are currently assigned to it.

Log and Block Suspicious IP Addresses

When you identify suspicious traffic from a specific IP address, create a rich rule that both logs and blocks the packets. This pairs nicely with Fail2ban on Fedora for automated intrusion prevention. The following example blocks the IP address 192.0.2.50 in the public zone:

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.50" log prefix="firewalld-block" level="info" drop'
sudo firewall-cmd --reload

The log prefix appears in the system journal, making it easy to verify the block. Check the logs with journalctl -k | grep firewalld-block to confirm that packets from the blocked IP are being dropped.

Ban Host Ranges with Ipsets

Rich rules can also reference ipsets, which excel at blocking large address lists without slowing packet processing. Use them when you need to ban entire networks or ranges used by botnets. The following example creates an ipset called blocked_ranges and adds a CIDR block:

sudo firewall-cmd --permanent --new-ipset=blocked_ranges --type=hash:net
sudo firewall-cmd --permanent --ipset=blocked_ranges --add-entry=203.0.113.0/24
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule source ipset=blocked_ranges drop'
sudo firewall-cmd --reload

Add or remove ipset entries as threats evolve using --add-entry and --remove-entry, then reload to apply changes instantly across every zone that references the ipset.

Troubleshooting Firewalld Issues

Even with proper configuration, firewall issues can block legitimate traffic or fail to apply rules correctly. The following troubleshooting steps address the most common problems administrators encounter when managing Firewalld on Fedora systems.

Service Won’t Start After Rule Changes

When Firewalld fails to start after adding custom rules, the most common cause is syntax errors in rich rules or direct interface commands. First, check the service status for error details:

sudo systemctl status firewalld

Look for lines indicating which rule failed to parse. If you recently added a rich rule, validate its syntax by testing it without the --permanent flag first. To recover from a broken permanent configuration, temporarily rename the zone file causing issues:

sudo mv /etc/firewalld/zones/public.xml /etc/firewalld/zones/public.xml.backup
sudo firewall-cmd --reload

This forces Firewalld to reload the default zone configuration from /usr/lib/firewalld/zones/, letting you start fresh and reapply rules one at a time.

Port Shows Open But Service Unreachable

When sudo firewall-cmd --list-ports shows a port as open but connections still fail, the issue often lies outside Firewalld. First, verify the application is actually listening on that port:

sudo ss -tlnp | grep :8080

If nothing appears, your application isn’t bound to the port. Next, check if you opened the port in the correct zone. Many users add ports to the default zone while their interface belongs to a different zone:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-ports

Additionally, confirm you made the rule permanent and reloaded. Runtime-only rules disappear after a firewall reload or system reboot. Always add --permanent and run sudo firewall-cmd --reload afterward.

Rules Disappeared After Reboot

If your firewall rules vanish after rebooting, you forgot the --permanent flag when adding them. Firewalld maintains two separate configurations: runtime (immediate but temporary) and permanent (survives reboots). To check what’s actually saved:

sudo firewall-cmd --permanent --list-all --zone=public

Compare this output to the runtime configuration (sudo firewall-cmd --list-all --zone=public). Missing rules in the permanent output explain why they disappeared. To save current runtime rules permanently:

sudo firewall-cmd --runtime-to-permanent

This command copies all active runtime rules into permanent storage in one step, avoiding the need to re-add each rule with --permanent.

Firewalld Conflicts with Docker or Libvirt

Docker and libvirt both manipulate iptables directly, occasionally conflicting with Firewalld’s zone-based management. If containers or virtual machines lose network connectivity after enabling Firewalld, the services are fighting over netfilter rules. For Docker, ensure you’re running a recent version (20.10+) that properly integrates with Firewalld. See our guide on installing Docker on Fedora for setup instructions. Restart Docker after Firewalld starts:

sudo systemctl restart firewalld
sudo systemctl restart docker

For libvirt, add the libvirt zone to Firewalld and assign virtual bridge interfaces to it. This prevents Firewalld from blocking virtualization traffic while maintaining security boundaries.

sudo firewall-cmd --permanent --zone=libvirt --change-interface=virbr0
sudo firewall-cmd --permanent --zone=libvirt --add-masquerade
sudo firewall-cmd --reload

Zone Assignment Doesn’t Stick

When interfaces keep reverting to the wrong zone after reconnecting, NetworkManager is overriding Firewalld’s assignment. NetworkManager stores zone information in connection profiles, taking precedence over Firewalld’s configuration. To permanently assign a zone to a connection:

sudo nmcli connection modify "Wired connection 1" connection.zone home
sudo nmcli connection up "Wired connection 1"

Replace “Wired connection 1” with your actual connection name (find it with nmcli connection show). This embeds the zone into the NetworkManager profile, ensuring it persists across reconnections.

Rich Rules Not Working as Expected

Rich rules process in the order they appear in the zone file, but Firewalld applies zone-level deny rules before allow rules. If your rich rule seems ignored, check rule ordering with:

sudo firewall-cmd --list-rich-rules --zone=public

Additionally, verify your rich rule syntax carefully. A missing quote or incorrect family (ipv4 vs ipv6) causes silent failures. Test rich rules in runtime mode first before making them permanent, allowing quick rollback if they don’t behave as expected.

Panic Mode Accidentally Enabled

Panic mode immediately drops all network traffic, cutting off remote SSH connections. If you suspect panic mode is active (usually after fat-fingering a command), check from the console:

sudo firewall-cmd --query-panic

Disable it immediately to restore connectivity:

sudo firewall-cmd --panic-off

Panic mode is strictly a runtime feature and doesn’t persist across reboots, so restarting the system also clears it. However, you’ll lose remote access until the system comes back up.

Quick Reference: Common Firewalld Commands

Bookmark this command cheat sheet for quick lookups when managing firewall rules on Fedora:

Task	Command
Check firewall status	sudo firewall-cmd --state
List all zones	sudo firewall-cmd --get-zones
Get default zone	sudo firewall-cmd --get-default-zone
List active zones	sudo firewall-cmd --get-active-zones
View zone details	sudo firewall-cmd --list-all --zone=public
Add service (temporary)	sudo firewall-cmd --add-service=http
Add service (permanent)	sudo firewall-cmd --permanent --add-service=http && sudo firewall-cmd --reload
Remove service	sudo firewall-cmd --permanent --remove-service=http && sudo firewall-cmd --reload
Open port (temporary)	sudo firewall-cmd --add-port=8080/tcp
Open port (permanent)	sudo firewall-cmd --permanent --add-port=8080/tcp && sudo firewall-cmd --reload
Close port	sudo firewall-cmd --permanent --remove-port=8080/tcp && sudo firewall-cmd --reload
Save runtime rules	sudo firewall-cmd --runtime-to-permanent
Reload rules	sudo firewall-cmd --reload
Block an IP	sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="1.2.3.4" reject'
Enable masquerading	sudo firewall-cmd --permanent --add-masquerade && sudo firewall-cmd --reload
Change default zone	sudo firewall-cmd --set-default-zone=home
Assign interface to zone	sudo nmcli connection modify eth0 connection.zone home
Emergency block all	sudo firewall-cmd --panic-on
Disable panic mode	sudo firewall-cmd --panic-off

Remove Firewalld from Fedora

While Firewalld is the recommended firewall solution for Fedora, you may need to remove it if you prefer an alternative firewall manager or are troubleshooting conflicts. The process involves stopping the service, disabling it from starting at boot, and then removing the package.

Disable and Stop the Service

Before removing Firewalld, stop the running service and disable it from starting on boot:

sudo systemctl disable --now firewalld

The --now flag stops the service immediately while also removing the boot-time symlink. Verify the service is inactive:

sudo systemctl status firewalld

○ firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; preset: enabled)
     Active: inactive (dead)

Uninstall the Package

Removing Firewalld leaves your system without firewall protection. If you’re connected via SSH on Fedora, ensure you have an alternative firewall configured or physical access to the machine before proceeding.

Remove Firewalld and its configuration:

sudo dnf remove firewalld

DNF automatically removes Firewalld along with any unused dependencies. Verify the removal by checking for the firewall-cmd command:

which firewall-cmd

If the command returns no output, Firewalld has been successfully removed.

Your custom zone configurations in /etc/firewalld/ remain on disk after package removal. To complete the cleanup, remove the configuration directory:

This command permanently deletes all custom zones, services, and ipsets you created. Only run this if you’re certain you won’t restore Firewalld later or need to reference your previous configuration.

sudo rm -rf /etc/firewalld/

Common Questions

Conclusion

Firewalld provides comprehensive network security for Fedora systems through zone-based management, dynamic rule updates, and rich language configurations. By understanding the fundamentals of firewall-cmd syntax, managing zones and services, and applying permanent vs temporary rules, you can confidently secure both desktop and server environments without sacrificing accessibility or uptime.