[PATCH 0/4] network: firewalld: fix routed network

[Daniel P. Berrangé]

On Thu, May 12, 2022 at 07:00:09PM +0100, Daniel P. Berrangé wrote:
> On Wed, May 11, 2022 at 11:41:51AM -0400, Eric Garver wrote:
> > This series fixes routed networks when a newer firewalld (>= 1.0.0) is
> > present [1]. Firewalld 1.0.0 included a change that disallows implicit
> > forwarding between zones [2]. libvirt was relying on this behavior to
> > allow routed networks to function.
> > 
> > New firewalld policies are added. This is done to use common rules
> > between NAT and routed networks. Policies have been supported since
> > firewalld 0.9.0.
> 
> For those following along, there's a helpful description of policies
> here, specifically explaining how its useful to the libvirt scenario:
> 
>   https://firewalld.org/2020/09/policy-objects-introduction

In reviewing these patches I've come to realize I'm still not
confident I'm understanding the interaction between traffic
we're managing at the firewalld  zones/policies.

For illustration let me assume the following setup:
[
   * Remote host on LAN (remote host IP 10.0.0.2)

   * eth0 public facing ethernet on the LAN (local host IP 10.0.0.5)

   * virbr0 isolated bridge device (local host IP 192.168.122.1)

   * vnet0 TAP device for a guest (guest IP 192.168.122.5)


   Remote host            Local host

  +----------+    LAN   +----------+   IP forward  +---------------+
  | 10.0.0.2 | -------- | 10.0.0.5 | --------------| 192.168.122.1 |
  | eth0     |          |  eth0    |   w/ NAT      |  virbr0       |
  +----------+          +----------+               +---------------+
                                                         |
							 | bridge port
                                                         |
                                                   +---------------+
                                                   | 192.168.122.5 |
						   | host: vnet0   |
						   | guest: eth0   |
						   +---------------+

IIUC zones are

   * 'libvirt' containing 'virbr0'
   * 'FedoraWorkstation' containing 'eth0'

Is 'vnet0' in a zone or not ?



Traffic flows


   * LAN Remote host (10.0.0.2) -> local host (10.0.0.5)

     Normal traffic nothing to do with libvirt

     Rules in <zone> FedoraWorkstation apply


   * LAN Remote host (10.0.0.2) -> guest (192.168.122.5)

     IP layer forwarding via eth0 (with conntrack match for NAT zone)

     ingress=FedoraWorkstation
     egress=libvirt

     Rules in <policy> libvirt-host-in apply ?


   * Local host (192.168.122.1) -> guest (192.168.122.5)

     Rules in <zone> libvirt apply ?


   * Local host (10.0.0.5) -> guest (192.168.122.5)

     NB, shouldn't happen as traffic should have originated
     from 192.168.122.1 instead.

     ingress=FedoraWorkstation
     egress=libvirt

     Rules in <policy> libvirt-host-in apply ?


   * Guest (192.168.122.5) -> Local host (192.168.122.1)

     Rules in <zone> libvirt apply ?

     Need to allow dhcp, dns, ssh. Feels like this
     should still be rules in the <zone> ?


   * Guest (192.168.122.5) -> Local host (10.0.0.5)

     NB, shouldn't happen as guest generally won't be
     aware of host's eth0 IP address.

     ingress=libvirt
     egress=FedoraWorkstation

     Rules in <policy> libvirt-nat-out apply ?

     Should not allow anything special related to virt,
     as dhcp/dns stuff should only be serviced from virbr0.
     So the libvirt-nat-out policy feels wrong for this
     case.


   * Guest (192.168.122.5) -> LAN remote host (10.0.0.2)

     ingress=libvirt
     egress=FedoraWorkstation

     Rules in <policy> libvirt-nat-out apply ?

     Need to allow all traffic


Is the above right, or any I getting mixed up somewhere ?

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|