Blog - Policy Objects: How to configure firewalld for routed networks in libvirt #14
Conversation
Based on advice from @erig0. Policy Objects achieve the functionality required.
erig0
force-pushed
the
routed_networks_libvirt_firewalld
branch
from
9393462
to
3af54e1
Compare
| VMs to host | ||
| ``` | ||
| firewall-cmd --permanent --new-policy libvirtToHost | ||
| firewall-cmd --permanent --policy libvirtToHost --set-target ACCEPT | ||
| firewall-cmd --permanent --policy libvirtToHost --add-ingress-zone libvirt | ||
| firewall-cmd --permanent --policy libvirtToHost --add-egress-zone FedoraServer | ||
| ``` |
There was a problem hiding this comment.
This is not needed. The traffic leaving the VM is already allowed by the libvirt zone.
|
@benblasco, I made quite a few changes. I added some clarity to why it happens and reduced the amount of things "opened" for the VMs. Please take a look. I'm ready to merge. Just waiting on your approval. |
erig0
force-pushed
the
routed_networks_libvirt_firewalld
branch
from
3af54e1
to
d0876fc
Compare
|
The blog suggestion looks reasonably sane from my POV as a libvirt maintainer. FWIW, if you think it'd further aid discoverability, feel free to submit a similar doc for publishing under the libvirt knowledgebase https://libvirt.org/kbase/ (src is https://gitlab.com/libvirt/libvirt/-/tree/master/docs/kbase) |
|
I just want to point out that the original intent of the libvirt zone was to allow all traffic in both directions to/from the VMs; it was added as a parallel to the iptables rules added by libvirt itself for routed networks. Here's an excerpt from https://libvirt.org/firewall.html:
Allow inbound, but only to our expected subnet. Allow outbound, but only from our expected Discussing this with Eric and reviewing old emails just now, I've learned that at the time the libvirt zone was originally created and tested, it worked due to a bug in the rules created by firewalld (which was a good thing, because at the time it wasn't possible to explicitly allow/deny forwarding via firewalld rules). So if we want to preserve historically desired/documented behavior of routed libvirt virtual networks, this should be made the default setup. |
The behavior changed in v1.0.0. See section "Default target is now similar to reject". There is a list of reasons why it was fixed.
Oof. If we want to restore that behavior then a policy that allows the forwarding needs to be added (basically the suggestion in this blog post). |
…sco/firewalld.github.io into routed_networks_libvirt_firewalld
|
Hi @erig0 I made a couple of minor changes in the interests of tidiness but otherwise it's good to merge from my point of view. Do we want to add some acknowledgement of the bug @lainestump referred to as part of the blog? I have a feeling that this bug may ultimately be what brought me here, because this all appeared to work without having to create a policy on my other server which was running Fedora 32 |
|
I'm holding off on merging this blog as it sounds like this should actually work out of the box. See this Fedora 35 bug: https://bugzilla.redhat.com/show_bug.cgi?id=2055706 |
Had accidentally copied the "not secure" configuration to the "secure" configuration. Fixed. Even if this never gets published I still want it to be correct for the current software versions.
erig0
force-pushed
the
master
branch
5 times, most recently
from
95b49d4
to
629347b
Compare
Patches have hit the libvir-list to fix this. The goal is to get to a native firewalld backend. Step one is fixing the routed network so you don't have to do any of the steps mentioned in this blog post. Since it is in progress of being fixed I won't be merging this post. Thanks though! |
Guest blog upon suggestion from @erig0. Originally published at the link below. I have updated it slightly and can pull it from my blog if it is published here.
https://blog.benblasco.com/routed_networks_libvirt_firewalld/
However @erig0 you mentioned that "simply noting that it's a dual post and linking back to your original would work."
Happy to go with whatever the firewalld team prefers!