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