7:52 a.m.
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(a)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(a)lists.fedorahosted.org
>
> https://lists.fedorahosted.org/admin/lists/firewalld-users@lists.fedoraho...
>
Regards,
Thomas
_______________________________________________
firewalld-users mailing list
firewalld-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/firewalld-users@lists.fedoraho...