On Wed, Jul 15, 2020 at 07:55:47AM -0400, Gunnar Niels wrote:
[..]
[Questions]
I suspect I'm stumbling because I'm using libvirt NAT instead of a
bridged device (which
admitedly I don't fully understand). Dumping the nft ruleset, it looks like my
zone settings strictly affect the zone's input chain.
Right. Firewalld does not yet support forward filtering. It's in the
works [1], but not functional yet.
[1]:
https://github.com/firewalld/firewalld/pull/639
At some point my packets
need to traverse the NAT from virbr1 (zone libvirt_discon) to my eth
NIC (zone public),
and back again. I'm not sure how this works, could someone shed some
light on that?
firewalld allows all output by default. If the ingress zone (i.e.
incoming interface is virbr1) uses --set-target=ACCEPT, then firewalld
will allow all forwarded packets as well.
The return path (world --> host) will be allowed if the connection
originated from the host (host --> world). This is done via a top level,
generic accept, "ct state established,untracked accept".
Do I need to enable masquerade on one of the zones here, and if so
which one or both?
When exactly do I need to enable masquerade?
No. libvirt should be setting up masquerade itself.
Are these considered FORWARDed packets, and therefore the INPUT chain
rules I've
actually written with my rich rule not apply? (They demonstrably are
not logging..)
Correct.