How does Firewalld create iptables structure

[ed greenberg]

My IPtables -L shows a pretty complex structure that seems to only be present when using firewalld.  For instance...

Such chains as FWDI_public (which invokes FWDI_public_pre, FWDI_public_log, FWDI_public_deny, FWDI_public_allow, and FWDI_public_post.

Same for FWDO_public, IN_public, etc.

Chain IN_public (2 references)
target     prot opt source               destination         
IN_public_pre  all  --  0.0.0.0/0            0.0.0.0/0           
IN_public_log  all  --  0.0.0.0/0            0.0.0.0/0           
IN_public_deny  all  --  0.0.0.0/0            0.0.0.0/0           
IN_public_allow  all  --  0.0.0.0/0            0.0.0.0/0           
IN_public_post  all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0

In all of the chains that call their corresponding _pre, _post, etc., I find that my _deny comes before my _allow.  This means that everything is denied, and the specific allows don't function.  On other servers, _allow precedes _deny, as one would expect.

My question is, "Does FirewallD create these chains and subchains?  If so, Where in Firewalld does the order that puts deny before allow get defined so I can fix it?

Ed

[Eric Garver]

On Thu, Feb 16, 2023 at 01:10:27PM -0000, ed greenberg wrote:
> My IPtables -L shows a pretty complex structure that seems to only be present when using firewalld.  For instance...
>
> Such chains as FWDI_public (which invokes FWDI_public_pre, FWDI_public_log, FWDI_public_deny, FWDI_public_allow, and FWDI_public_post.
>
> Same for FWDO_public, IN_public, etc.
>
> Chain IN_public (2 references)
> target     prot opt source               destination         
> IN_public_pre  all  --  0.0.0.0/0            0.0.0.0/0           
> IN_public_log  all  --  0.0.0.0/0            0.0.0.0/0           
> IN_public_deny  all  --  0.0.0.0/0            0.0.0.0/0           
> IN_public_allow  all  --  0.0.0.0/0            0.0.0.0/0           
> IN_public_post  all  --  0.0.0.0/0            0.0.0.0/0           
> ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
>
> In all of the chains that call their corresponding _pre, _post, etc.,
> I find that my _deny comes before my _allow.  This means that

_deny has always been before _allow.
> everything is denied, and the specific allows don't function.  On
> other servers, _allow precedes _deny, as one would expect.

That does not sound correct. If you enable something it will go to the
_allow chain. By default _deny is empty.
> My question is, "Does FirewallD create these chains and subchains?

Yes.
> If so, Where in Firewalld does the order that puts deny before allow
> get defined so I can fix it?

It's hard coded.

If you want more granular control your options are:

- rich rules with priority specified
  - policies with priority specified

[Ed Greenberg]

On 2/16/23 8:52 AM, Eric Garver wrote:
> _deny has always been before _allow.

Hi Eric,

Given these rules...

rich rules:
     rule family="ipv4" source address="192.168.1.81" service name="sip" 
accept
     rule family="ipv4" source address="66.241.96.221" service 
name="sip" accept
     rule family="ipv4" source address="64.2.142.93" service name="sip" 
accept
     rule family="ipv4" source address="192.168.1.3" service name="sip" 
accept
     rule family="ipv4" source address="192.168.1.200" service 
name="sip" accept
     rule family="ipv4" service name="sip" reject

would you expect the specified IP addresses to get through, or would the 
deny before allow cause them all to be kept out? My experience is that 
they are not getting through. If I remove the reject rule, they get 
through but so does everything else :(

Thanks,

Ed

[Eric Garver]

On Thu, Feb 16, 2023 at 11:41:29AM -0500, Ed Greenberg wrote:
> On 2/16/23 8:52 AM, Eric Garver wrote:
> > _deny has always been before _allow.
>
> Hi Eric,
>
> Given these rules...

[..]
> rule family="ipv4" service name="sip" reject

This rule is rejecting _all_ traffic. You are not specifying any order
(priority) so this reject goes to the _deny chain which always executes
before the _allow chain.

I think this blog post should clarify things for you.

https://firewalld.org/2018/12/rich-rule-priorities

tl;dr use 'rule priority=N ...' in your rich rules.

[Ed Greenberg]

Got it. Thanks for the blog posting. Also for the hint on priority. I will
get this thing straightened out.

On Thu, Feb 16, 2023, 11:56 Eric Garver  wrote:
> On Thu, Feb 16, 2023 at 11:41:29AM -0500, Ed Greenberg wrote:
> > On 2/16/23 8:52 AM, Eric Garver wrote:
> > > _deny has always been before _allow.
> >
> > Hi Eric,
> >
> > Given these rules...
>
> [..]
> > rule family="ipv4" service name="sip" reject
>
> This rule is rejecting _all_ traffic. You are not specifying any order
> (priority) so this reject goes to the _deny chain which always executes
> before the _allow chain.
>
> I think this blog post should clarify things for you.
>
> https://firewalld.org/2018/12/rich-rule-priorities
>
> tl;dr use 'rule priority=N ...' in your rich rules.