As I continued to play with this I found out some more information:

For 'a', it turns out that you can do this but for some reason either a 'port' or 'protocol' (or, I assume, both) is required. I don't understand why as it is perfectly reasonable to want to expect all traffic from one address to another without caring about port or protocol. It's also unfortunate that error messages are misleading and essentially useless.

For 'b', I think the behavior I was seeing is odd but, even more interesting, is that when using NetworkManager one actually has to provide the 'ZONE=' parameter in ifcfg-ethN to make reboots and firewalld restarts work predictably. Simply relating interfaces to zones in firewalld config files doesn't work correctly when using NetworkManager.

There are a lot of little quirks with firewalld it seems. I am using version 0.3.9-11.el7. I really haven't gotten on board with firewalld at this point. I actually think that using iptables directly was much more intuitive. I think the only real benefit I've seen with firewalld is the 'forced' organization of the chains which makes addition and removal of rules less risky and less impactful on other rules.

On Tue, Mar 29, 2016 at 5:16 AM, Thomas Woerner twoerner@redhat.com wrote:

Hello,

On 03/18/2016 06:27 PM, Lesley Kimmel wrote:

...

All;

I am ramping up on firewalld (RHEL7) and was looking for confirmation on a couple of quirks that I noticed. If I'm wrong please correct me on the appropriate course(s) of action:

a) I was attempting to configure a private NIC to allow only multicast traffic (IP range) from a specific subnet: $ firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<allowed_subnet>" destination address="<multicast_address>" accept' OUTPUT: Error: INVALID_RULE: destination action It appears that it is not permissible to use BOTH source and destination address in a rich rule even though this is a perfectly acceptable IPTables rule. Is this the intended behavior or is a fix in the works? I had to do a direct rule with the above criteria ($ firewall-cmd --permanent --direct --add-rule ipv4 filter IN_internal_allow 0 -s <allowed_subnet> -d <multicast_address> -j ACCEPT

This should be possible to allow with some further checks, I think.

b) When having multiple interfaces (e.g. eth0, eth1) and a single

...

'default' zone, both interfaces are included in that default zone. However, I noticed that when having a default zone (say 'public'), adding one of the interfaces (eth1) to a second zone ('internal'), and reloading the firewall eth0 is no longer in the default zone. In fact is is not configured in any zone. It seems that once I add one interface explicitly to a zone I have to explicitly add all interfaces to some zone(s). Why don't unspecified interfaces automatically fall into the default zone?

Unspecified interfaces are automatically handled by the default zone.

Which firewalld version are you using?

Thanks,

...

-LJK

---

firewalld-users mailing list firewalld-users@lists.fedorahosted.org

https://lists.fedorahosted.org/admin/lists/firewalld-users@lists.fedorahoste...

Regards, Thomas _______________________________________________ firewalld-users mailing list firewalld-users@lists.fedorahosted.org

https://lists.fedorahosted.org/admin/lists/firewalld-users@lists.fedorahoste...