URL:
Reporter RHNID:
Section: -
Language:
Workaround:

Description: Page 98 of the student guide lists 4 basic ordering rules:
1. Any port forwarding and masquerading rules set for that zone.
2. Any logging rules set for that zone.
3. Any allow rules set for that zone.
4. Any deny rules set for that zone.
In then reads, "In all cases, the first match will win."

The ordering of rules 3 & 4 seems to be correct in some cases, but not in others. Consider the lab "Practice: Configuring a Firewall" on pages 94-96. I'm sending all traffic from 172.24.X.0/24 to the work zone. The work zone has a rule allowing access to https. I have verified that I can access https://serverX.example.com from desktopX.

Given the ending condition of the lab "Practice: Configuring a Firewall" (pages 94-96), what if I wanted to deny access to https from 172.24.X.254? Based on rule 3, this machine should be granted access because it belongs to the 172.24.X.0/24 network. According to this rule ordering, adding a reject rule for this machine shouldn't work. This didn't make sense to me, so I decided to test it out. I added the following rule and reloaded the firewall:

1. firewall-cmd --zone=work --add-rich-rule='rule family=ipv4 source address=172.25.0.254/32 port port=443 protocol=tcp reject' --permanent

I found that I was still able to access https://server0.example.com from desktop0, but that I was no longer able to access it from classroom.example.com. In this scenario, the deny rule was used before the allow rule.

This made me wonder if the ordering was based on the most specific rule winning (i.e. a rule for an individual machine is more specific than the rule for a network). After some tests, I found that this doesn't appear to be the case. The scenarios that I'm thinking about were relatively easy to implement with iptables by simply ordering rules in the order in which I wanted them to be evaluated. This definitely seems trickier with firewalld and I'm guessing that other instructors may find this to be a little challenging at first. Here are two more scenarios, one of which I have been able to figure out and the other I haven't been able to yet.

Scenario 1: If I am sending all traffic from a network (172.25.X.0/24) to a specific zone (work), how do I allow only one machine on that network (172.25.X.10) to access a service (https)? I tried "firewall-cmd --permanent --zone=work --add-service=https" and then I added a two rich rules (one that allowed https access for 172.25.X.10/32 and one that denied access to https for 172.25.X.0/24). I found that all machines on 172.25.X.0/24 were able to access https. In this case, it seems like the general allow rule for https was the one that was used. To get this to work, I removed the generic https rule as well as the rich rule that denied access to 172.25.X.0/24. I retained the rich rule allowing https access for 172.25.X.10/32.

Scenario 2: With iptables, it was easy to add a global LOG rule right above a global REJECT rule. This made troubleshooting easier since you could check /var/log/messages if you were having trouble connecting to a service from a remote machine. I'm wondering how this would be handled with firewalld. Certainly I can create a rich rule to log (as part of either an accept or a reject rule), as demonstrated on pages 100-102, but it seems like the rule needs to include information about the service or port/protocol. How can I create a logging rule that will help me identify what the firewall is blocking when I don't know which service or port/protocol is being blocked?

I started this JIRA issue with the intent of indicating that I thought the order of rules 3 & 4 needed to be reversed. This led me to test various scenarios where I found that the listed order is good for some scenarios, but incorrect for others. I don't know if anything needs to change or not in the student or instructor guides, but I wanted to document what I found in case it helps other instructors.