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

[Eric Garver]

On Thu, May 12, 2022 at 08:04:28PM +0100, Daniel P. Berrangé wrote:
> 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.

It's confusing because it's a combination of iptables (libvirt) and
firewalld (nftables). And they filter independently. Think of it as
having to pass through two firewalls.

Hopefully I got it all correct below.

> 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 ?

No. Only the bridge interface is added to the zone. The vnet* interfaces
don't have addresses.

> 
> 
> 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

True.

> 
>    * 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 ?

False. There are no explicit firewalld rules for this.

Existing connections would be implicitly allowed by a top-level "ct
state" match in FORWARD.

> 
>    * Local host (192.168.122.1) -> guest (192.168.122.5)
> 
>      Rules in <zone> libvirt apply ?

False. No rules explicit rules apply.

Firewalld allows outbound by default.

> 
>    * 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 ?

False. There are no explicit firewalld rules for this.

New connections would be denied. Existing (originating from VM) would be
allowed.

> 
>    * 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> ?

True. This is handled by the current zone definition.

This series moves them into libvirt-to-host. You used the name
libvirt-host-in, which may be a better name for the policy. :)

> 
>    * 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.

False. I think this is still considered INPUT traffic since it's going
to the local network stack.

So the "libvirt" zone and libvirt-to-host would apply.

Would be

        ingress=libvirt
        egress=HOST

> 
>    * 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

True.

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

Answered all inline.