[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewalld-users
Subject:    Re: Re rich rules
From:       "D. Hugh Redelmeier" <hugh () mimosa ! com>
Date:       2020-07-31 20:15:29
Message-ID: alpine.LFD.2.23.451.2007311530290.5127 () redeye ! mimosa ! com
[Download RAW message or body]

[threading still wrong]

Eric asked:

| On Fri, Jul 31, 2020 at 04:11:51PM -0000, D. Hugh Redelmeier wrote:

| > firewalld.richlanguage(5) section "Information about logging and
| > actions" does not say on which chain or at which priority masquerading
| > is applied.  So my use of negative priority was an experiment, after
| > trying no priority.
| 
| That chain suffix/sorting (_pre, _log, _deny, _allow, _post) applies
| to all rich rules. But the different chain (input, prerouting,
| postrouting) used by a rich rule varies depending on the rich rule.
| "service value=... accept" would go to input. forward-port would go to
| prerouting, masquerade goes to postrouting.

The "Information about logging and actions" section lists chains but
does not actually say that the chains are applied in the listed order.
It probably isn't obvious to all readers.  This should be made
explicit.

I'm not sure but for at least the external zone, this list is only about 
packets coming into an interface.  This should be made explicit in the 
documentation.

(I used the words ingress and egress relative to an interface (zone)
whereas you seemed to use it for a network (eg. a LAN).)

If the rules (other than masquerade or logging) only apply in ingress,
then source and destination are clear.  But only if that's true.

In an abstract way, masquerading is done in both directions.  It's
just that inbound traffic is handled by connection tracking and not
explicit masquerading rules.  This should be spelled out in the
documentation.

I think that it is important that firewalld users not have to
understand the lore of what's underneath it.  I don't even know what
that is by default.  (Seems to be netfilter on Fedora 32.)

| > I had a nagging fear that my rules might apply on egress as well.
| 
| Masquerading _must_ be applied on postrouting (egress).
| 
| With the few exceptions (forward-port, masquerade) firewalld rules
| apply to the input chain (ingress).

I wanted to make sure no local IP addresses leaked to the internet.
So an egress rule seemed reasonable.  Nothing in "Information about
logging and actions" made it clear to me that my rules were
ingress-only.

If "source" and "destination" keywords were replaced with "outside" and 
"inside", one rich rule could specify both ingress and egress. But you 
don't have rules that are bidirectional, so that doesn't matter.  This 
certainly was part of my confusion.

I'm glad you are about to land forwarding and egress rich filters.  I
didn't see documentation.  I didn't dig into your git commits.
_______________________________________________
firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org
To unsubscribe send an email to firewalld-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/firewalld-users@lists.fedorahosted.org

[prev in list] [next in list] [prev in thread] [next in thread]