Managing Network Access in CentOS with Firewalld Zones

Solving the Volatile Rule Problem

The primary challenge when managing network traffic in CentOS (and RHEL-based systems) is the distinction between runtime and permanent configurations. A common mistake is applying a rule that works immediately but vanishes after a reboot or a service restart. To ensure a port remains open, you must apply the rule with the --permanent flag and then reload the daemon to move that configuration into the active runtime state.

Understanding Zone-Based Filtering

Firewalld does not use a single linear list of rules. Instead, it uses zones—predefined sets of trust levels. Each network interface or source IP address is assigned to exactly one zone at a time. For example, the public zone is designed for untrusted networks where you only open specific ports, while the trusted zone allows all network connections.

Worked Example: Securing a Web Server

Assume you are running a web server on CentOS 7 or 8 and need to allow HTTP (port 80) and HTTPS (port 443) traffic while ensuring these settings survive a system crash or update. Run these commands as a user with sudo privileges on the local terminal.

# 1. Verify which zone the active interface (e.g., eth0) is using
sudo firewall-cmd --get-active-zones

# 2. Add HTTP and HTTPS ports to the public zone permanently
sudo firewall-cmd --zone=public --add-port=80/tcp --permanent
sudo firewall-cmd --zone=public --add-port=443/tcp --permanent

# 3. Apply the permanent changes to the current runtime
sudo firewall-cmd --reload

# 4. Verify the active rules for the public zone
sudo firewall-cmd --zone=public --list-all

Expected Result: The --list-all command should show ports: 80/tcp 443/tcp under the public zone section. If you omit --permanent, the port opens immediately, but --list-all will show it gone after a reboot.

Advanced Logic with Rich Rules

Standard zone rules are binary (open or closed). For more granular control, such as limiting connection attempts to prevent brute-force attacks, use rich rules. These allow you to combine source IPs, ports, and logging into a single logic statement.

Example: Limit a specific IP address to 3 connections per minute on SSH (port 22):

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port="22" protocol="tcp" accept limit value="3/m"'
sudo firewall-cmd --reload

Limitations and Common Pitfalls

• Interface Misassignment: If an interface is assigned to the drop zone, all traffic is discarded regardless of the ports you open in the public zone. Always check --get-active-zones first.
• Reload vs. Restart: Use --reload. A full service restart (systemctl restart firewalld) may momentarily drop existing connections, whereas a reload updates the rules without breaking established sessions.
• NetworkManager Conflict: CentOS uses NetworkManager to handle interface profiles. If a profile explicitly assigns an interface to a specific zone, manual firewall-cmd zone changes may be overridden when the network interface restarts.

Verification and Diagnostics

To verify that your configuration is working from an external machine, use a network tool like curl or telnet to test the specific port:

# Run from a remote client machine
curl -I http://your-centos-ip

If the connection times out but firewall-cmd --list-all shows the port is open, the issue likely resides in an external cloud security group (like AWS SG or Azure NSG) or a physical hardware firewall upstream from the CentOS server.

Rollback Procedure

If a rule causes a loss of connectivity or a security vulnerability, remove the permanent rule and reload:

sudo firewall-cmd --zone=public --remove-port=80/tcp --permanent
sudo firewall-cmd --reload