(In reply to Mario Gamboa from comment #0)
> Expected results:
> The rule must be works if we add in the gui via passthrough or via shell
> with the permanent option in the firewall-cmd

The '--permanent' option in firewall-cmd (shell) or
the 'Permanent' view in firewall-config (gui) modifies *only* permanent configuration, not the runtime.

To do a change in 'runtime' as well as 'permanent' configuration you either have to run the firewall-cmd twice, once with '--permanent' and once without it, for example:

# firewall-cmd --permanent --direct --passthrough ipv4 -A IN_drop_allow -p icmp --icmp-type=8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# firewall-cmd --direct --passthrough ipv4 -A IN_drop_allow -p icmp --icmp-type=8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

*or* add it to permanent configuration and then reload firewalld, i.e.
# firewall-cmd --permanent --direct --passthrough ipv4 -A IN_drop_allow -p icmp --icmp-type=8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# firewall-cmd --reload

See also 'Permanent Options' in firewall-cmd(1) man page.

Hi jiri

This is the problem actually when the customer try this on the "drop zone" is not working as expected the same happen if he try to open the service of ssh 

# firewall-cmd --permanent --direct --passthrough ipv4 -A IN_drop_allow -p icmp --icmp-type=8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# firewall-cmd --reload

only work in runtime for the drop zone and we can't make permanent the rule for this zone, 

if the customer run like this the command works fine but is not permanent for the drop zone 

# firewall-cmd  --direct --passthrough ipv4 -A IN_drop_allow -p icmp --icmp-type=8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# firewall-cmd --reload


In the public zone works ok

Just to be clear this is happen when the customer change to the zone drop in the zone public is works as expected.

Ok, I see it now. But I can see the same even with 'public' zone.

The reason is that when you reload firewalld, firewalld adds the direct rules *before* the chains for zones are created. The chains for zones are first created in a moment when a interface is associated with a zone.

So it fails because IN_drop_allow (or even IN_public_allow in my case) does not yet exist in that moment.

Besides fixing the issue with being able to add rules to chains of zones, there is also another idea to use icmp-block more like an icmp-filter, that is rejecting for zones using the default or ACCEPT target and that is accepting icmp types for zones using the reject or drop targets.

Is there interest in a change like this?

Fixed upstream in 
  https://github.com/t-woerner/firewalld/commit/a3f82d2cd4530e409a2a7dc778afa0f9b1becc5c
and
  https://github.com/t-woerner/firewalld/commit/1d9158dc81c6c78f34f2f368b6db9096504f366d

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Thomas, Mario's account has been closed.

Personally I like function behind the idea but this implementation might be very confusing. I mean that function of this field would invisibly depend on default-target which is not shown even in --zone-info=<zone>.
Instead, I suggest 'icmp-filter' (backward compatibile with icmp-block) and added notation like '!' before the list. What do you think?

idea from comments 11 and 15 now has a separate bug 1325335

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2597.html