Firewalld Quirks

[Lesley Kimmel]

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

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?

Thanks,
-LJK

[Thomas Woerner]

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
> [e-mail]
> https://lists.fedorahosted.org/admin/lists/[e-mail]...

Regards,
Thomas

[Lesley Kimmel]

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  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
> > [e-mail]
> >
> > https://lists.fedorahosted.org/admin/lists/[e-mail]...
>
> Regards,
> Thomas
> _______________________________________________
> firewalld-users mailing list
> [e-mail]
>
> https://lists.fedorahosted.org/admin/lists/[e-mail]...