How to Install FirewallD GUI on Fedora

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. On Fedora Workstation, the default is typically “FedoraWorkstation”; on Fedora Server it’s “FedoraServer”; and on other spins it’s usually “public.”

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

cockpit dhcpv6-client 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 cockpit web console service from the public zone:

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

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 Trust Levels Explained

Zones range from “drop” (zero trust, maximum security) to “trusted” (full trust, no restrictions). Here’s how each zone behaves and when to use it:

Drop Zone

The strictest zone available, offering maximum security by making your system invisible to attackers:

• Trust Level: Zero trust, maximum security
• Default Behavior: Silently drops all incoming packets without any reply; only outgoing connections work
• Best Used For: Hostile public Wi-Fi at airports or hotels where you suspect network monitoring and want zero incoming traffic

Block Zone

Similar to drop zone but actively rejects connections with ICMP messages:

• Trust Level: Zero trust, maximum security
• Default Behavior: Sends ICMP rejection messages (host-prohibited for IPv4, admin-prohibited for IPv6) back to the sender instead of silently dropping packets
• Best Used For: Untrusted networks where you want to discourage connection attempts while remaining RFC-compliant with rejection messages

Public Zone (Default)

The default zone for most Fedora installations, balancing security with essential access:

• Trust Level: Low trust, assumes untrusted network
• Default Behavior: Only allows services you explicitly enable; SSH (port 22) and DHCP client traffic permitted by default
• Best Used For: Laptops, workstations, or servers on untrusted networks like coffee shops, coworking spaces, or cloud providers where neighbor instances share the same network segment

External Zone

Designed for routers and gateways that bridge two networks:

• Trust Level: Low trust for external-facing interfaces
• Default Behavior: Masquerading (NAT) enabled by default; assumes your system connects an untrusted external network (internet) to a trusted internal network (LAN)
• Best Used For: Configuring a Fedora system as a home router, VPN gateway, or network appliance that routes traffic between networks while hiding internal addresses

DMZ Zone

Created for demilitarized zone servers that face the public but need isolation from internal systems:

• Trust Level: Low trust with strict service limitations
• Default Behavior: Only selected services reach DMZ hosts, reducing damage if one gets compromised; blocks direct access to internal infrastructure
• Best Used For: Web servers, mail servers, or any public-facing service that shouldn’t directly touch your internal network; for example, assign your Apache server’s interface to the DMZ zone while keeping database servers on the internal zone

Work Zone

Provides moderate trust for office networks where collaboration matters:

• Trust Level: Medium trust, balances security with productivity
• Default Behavior: Generally trusts coworkers’ machines while maintaining basic protection against accidents or compromised workstations; common services like file sharing and printers receive easier access
• Best Used For: Corporate environments where network segmentation exists but colleague collaboration requires more open policies than public networks

Home Zone

Similar trust level to work zone but tailored for residential environments:

• Trust Level: Medium trust, prioritizes convenience
• Default Behavior: Assumes you trust other devices (family members’ phones, smart TVs, IoT devices) with slightly relaxed rules; services like Samba file sharing, mDNS for network discovery, and DHCP client traffic typically allowed
• Best Used For: Home network interfaces where convenience matters more than strict security, though you should still manually configure which services to expose

Internal Zone

Designed for trusted internal networks behind your firewall perimeter:

• Trust Level: High trust for protected internal networks
• Default Behavior: Similar to home zone but intended for business internal networks where you have high confidence in endpoint security
• Best Used For: Internal management interfaces, backup networks, or server-to-server communication channels that never touch the internet directly

Trusted Zone

Accepts all network traffic without restrictions, effectively disabling the firewall:

• Trust Level: Full trust, no restrictions
• Default Behavior: Accepts all traffic without filtering; firewall is effectively disabled for that interface
• Best Used For: VPN tunnels, encrypted WireGuard interfaces, or direct connections between trusted systems where another layer already handles security; never assign internet-facing interfaces to this zone unless you fully understand the security implications

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. Therefore, 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. 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 Tasks

This quick-reference section highlights the most frequently used Firewalld commands. Bookmark it for fast lookups when managing firewall rules on Fedora systems.

Check firewall status: Returns whether the daemon is running.

sudo firewall-cmd --state

List all zones: Displays every built-in and custom zone name.

sudo firewall-cmd --get-zones

Get the default zone: Confirms which zone new interfaces join.

sudo firewall-cmd --get-default-zone

List active zones: Shows which zones currently have interfaces assigned.

sudo firewall-cmd --get-active-zones

View zone details: Lists services, ports, targets, and rich rules for a zone.

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

Add a service temporarily: Grants access until the next reload or reboot.

sudo firewall-cmd --add-service=http

Add a service permanently: Keeps the service open across reboots.

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

Remove a service: Close the service using the same flags you used to open it.

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

Open a port temporarily: Helpful for quick tests or short maintenance windows.

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

Open a port permanently: Keeps the port available after reboots.

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

Close a port: Removes a previously opened port from the zone.

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

Save runtime rules: Copies every active runtime rule into the permanent configuration.

sudo firewall-cmd --runtime-to-permanent

Reload firewall rules: Applies permanent configuration changes without dropping connections.

sudo firewall-cmd --reload

Block an IP address: Use a rich rule to reject traffic, then reload.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="1.2.3.4" reject'
sudo firewall-cmd --reload

Enable masquerading (NAT): Required when the system routes traffic between networks.

sudo firewall-cmd --add-masquerade --permanent
sudo firewall-cmd --reload

Change the default zone: Immediately affects any new network connection.

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

Assign an interface to a zone: Persistently map a NetworkManager connection profile to a zone.

sudo nmcli connection modify eth0 connection.zone home
sudo nmcli connection up eth0

Emergency block all traffic: Panic mode drops every packet immediately.

sudo firewall-cmd --panic-on

Disable panic mode: Restores normal firewall operation.

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; delete them manually with sudo rm -rf /etc/firewalld/ if you want a complete cleanup.

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.