Re: Re rich rules
On Fri, Jul 31, 2020 at 04:15:29PM -0400, D. Hugh Redelmeier wrote:
[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.
That's not true. Masquerade for example applies when the packets are
leaving via the zone, e.g. internal --> external. In the nat table look
at the chain POST_external.
(I used the words ingress and egress relative to an interface (zone)
whereas you seemed to use it for a network (eg. a LAN).)
I don't think our terminology is different. We're just looking at it
from different perspectives: a) the network point of view (zones) or b)
interfaces.
ingress = packet came IN via an interface assigned to the zone
egress = packet goes OUT via an interface assigned to the zone
ingress = packet came IN from a network segment/subnet
egress = packet goes OUT to a network segment/subnet
If the rules (other than masquerade or logging) only apply in
ingress,
then source and destination are clear. But only if that's true.
It is 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.)
"It should be spelled out in the documentation"
and
"it is important that firewalld users not have to understand what's
underneath"
are sort of contradicting statements.
That being said, I'm okay with making it explicit in the documentation.
[..]