Right now, I seem to be unable to ping, run traceroute or perform lookups via IPv6 while firewalld is turned on. This is within the VMs that I am running.
The VMs were created libvirt/qemu and are attached to the main system via a Bridge Interface.
IPv6 ping, run traceroute or perform lookups work on the host whether Firewalld is turned on or not.
I have turned firewalld off and all the above functions, seem to work within the VMs. So I am thinking it could be a missing/blocked set of rules that may have not been added to the libvirtd zone or another zone. Please be aware that the bridge interface in this scenario is managed by network manager.
Are there any suggestions of any rules to implement to allow?
I have had a look at this guide here (https://superuser.com/questions/1775676/which-inbound-outbound-rules-are-nec...). Although it is Windows based there were 3 things that stood out to me which I believe I may need to get enabled for IPv6 for the VMs.
- ICMPv6 - Neighbor Discovery - DHCPv6
This wasn't part of the guide, but would there be a rule needed for this? - Allowing DNS for IPv6
26.01.2025 20:53, Mark Savenent via firewalld-users wrote:
Right now, I seem to be unable to ping, run traceroute or perform lookups via IPv6 while firewalld is turned on. This is within the VMs that I am running.
It is unclear where you top firewalld - on the host on in the VM.
The VMs were created libvirt/qemu and are attached to the main system via a Bridge Interface.
Bridge interface can be used in different topologies. You need to provide more details about your configuration.
IPv6 ping, run traceroute or perform lookups work on the host whether Firewalld is turned on or not.
I have turned firewalld off and all the above functions, seem to work within the VMs. So I am thinking it could be a missing/blocked set of rules that may have not been added to the libvirtd zone or another zone. Please be aware that the bridge interface in this scenario is managed by network manager.
Are there any suggestions of any rules to implement to allow?
I have had a look at this guide here (https://superuser.com/questions/1775676/which-inbound-outbound-rules-are-nec...). Although it is Windows based there were 3 things that stood out to me which I believe I may need to get enabled for IPv6 for the VMs.
- ICMPv6
- Neighbor Discovery
- DHCPv6
This wasn't part of the guide, but would there be a rule needed for this?
- Allowing DNS for IPv6
Firewalld is on the host. With the bridge interface (which the VMs are assigned to) assigned to the public zone.
Here is a log of the result of firewall-cmd --list-all-zones
https://privatebin.net/?27fe5a1d6e9ef117#7V6at5MXNo9ajCekHVj7PeHoQXJA5NwF1vC...
Also here are pictures to how the Bridge is configured. I believe it uses a vnet device to connect the bridge to the virtual machine.. https://ibb.co/vQ3b9K9 https://ibb.co/sjHfKb7
On Sun, Jan 26, 2025 at 05:53:38PM -0000, Mark Savenent via firewalld-users wrote:
Right now, I seem to be unable to ping, run traceroute or perform lookups via IPv6 while firewalld is turned on. This is within the VMs that I am running.
It sounds like you're using the "NAT" network. IIRC, that only NATs IPv4 and IPv6 is expected to be routed. There are no rules in firewalld to support that. You could create them yourself (use policies).
IMO, this is a libvirt bug. libvirt should be creating these rules for you.
FWIW, I fixed the "routed" network a year or so ago.
I have tried in the past to add native firewalld support to libvirt, but it was rejected. I encourage you to file bugs against libvirt asking for native firewalld support.
The VMs were created libvirt/qemu and are attached to the main system via a Bridge Interface.
IPv6 ping, run traceroute or perform lookups work on the host whether Firewalld is turned on or not.
I have turned firewalld off and all the above functions, seem to work within the VMs. So I am thinking it could be a missing/blocked set of rules that may have not been added to the libvirtd zone or another zone. Please be aware that the bridge interface in this scenario is managed by network manager.
Are there any suggestions of any rules to implement to allow?
You'll have to create a policy that allows traffic from the "libvirt" zone to any other zones.
e.g. (untested)
# firewall-cmd --permanent --new-policy libvirtRouted # firewall-cmd --permanent --policy libvirtRouted --add-ingress-zone libvirt # firewall-cmd --permanent --policy libvirtRouted --add-egress-zone ANY # firewall-cmd --permanent --policy libvirtRouted --set-target ACCEPT # firewall-cmd --reload
I'm not sure if you'll need anything else. You may also have to set linux sysctls to enable IPv6 routing.
I have had a look at this guide here (https://superuser.com/questions/1775676/which-inbound-outbound-rules-are-nec...). Although it is Windows based there were 3 things that stood out to me which I believe I may need to get enabled for IPv6 for the VMs.
- ICMPv6
- Neighbor Discovery
- DHCPv6
firewalld allows these for the host side by default. The VMs will be on the libvirt bridge network. ND, etc. are local to the subnet and won't be routed.
This wasn't part of the guide, but would there be a rule needed for this?
- Allowing DNS for IPv6
-- _______________________________________________ firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/firewalld-users@lists.fedorahos... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 1/27/25 1:16 PM, Eric Garver via firewalld-users wrote:
On Sun, Jan 26, 2025 at 05:53:38PM -0000, Mark Savenent via firewalld-users wrote:
Right now, I seem to be unable to ping, run traceroute or perform lookups via IPv6 while firewalld is turned on. This is within the VMs that I am running.
It sounds like you're using the "NAT" network. IIRC, that only NATs IPv4 and IPv6 is expected to be routed.
The screenshot provided by Mark (what management app is that a screenshot of anyway?) shows the bridge device is named "br0", which isn't the normal naming of a bridge created for a libvirt virtual network - these are normally named "virbrN" (where N is some number) unless a user manually changes the name of the bridge (almost nobody does, so libvirt's "default" network usually uses a bridge device named "virbr0"). This leads me to believe that Mark is not, in fact, using a libvirt virtual network for his guests' connections, but is just connecting the guest interfaces to a bridge device that was setup outside of libvirt using the host's network managment (e.g. NetworkManager). This could be determined for certain if Mark could send the "<interface>" section of his guest's XML libvirt config (which can be obtained with the command "virsh dumpxml $guestname").
(side comment: it is much more useful to provide config information in text format, e.g. a snip from libvirt's XML for the guest, or the contents of a .conf file, rather than a screenshot, since the text in a screenshot can't later be searched for in the archives. A snippet of text also takes up much less space.)
There are no rules in firewalld to support that. You could create them yourself (use policies).
IMO, this is a libvirt bug. libvirt should be creating these rules for you.
When libvirt is configured to connect a guest to an existing bridge device on the host (using "<interface type='bridge'> in the guest config), it doesn't add *any* firewall rules - they are only added if the guest is connected to a libvirt-managed virtual network (using <interface type='network'/>) - those networks are constructed using a bridge device created by libvirt in combination with packet filtering rules (traditionally iptables, but these days nftables) that differ based on the forwarding mode (NAT, routed, or isolated).
If Mark is using <interface type='bridge'> to connect to an existing system (which seems more likely based on his interface type in the screenshot being "Bridge to LAN", and the bridge device being named "br0") then any firewall issue can't be a libvirt issue because libvirt doesn't interfere with firewall rules in this case - it is completely the responsibility of the user to set these rules up outside of libvirt (just as they setup the bridge device outside of libvirt).
Mark, can you please send the contents of the "<interface>" section of your guest's XML? (Also, if the <interface> really is type='network', then also send the output of "virsh net-dumpxml $networkname", where "$networkname" is the name given in the <source> subelement of <interface> in the guest). I could be completely misreading the partial clues that have provided by your screenshots, and that information would remove any doubt one way or the other.
FWIW, I fixed the "routed" network a year or so ago.
I have tried in the past to add native firewalld support to libvirt, but it was rejected.
"Rejected" is a bit too harsh :-) At the time I was adding an alternate backend for virtual networks that used nftables rather than iptables, your patches conflicted with mine, and I promised to rework your patches (which were hardcoded to always use a firewalld backend as long as firewalld was enabled) to merge properly with my other work (which made the default backend configurable at build-time, automatically selected based on circumstances at runtime, and also overridable with a user config setting for circumstances where the default didn't work). To my discredit, I have continued to not do that work for the last two years (!!) :-(.
(Also, I think danpb discovered when he was testing your patches that the behavior was different wrt. inter-network communication when the firewalld backend was used; I don't remember the details, but I *think* it might have been that guests on two different NAT networks were able to communicate with each other when using the firewalld backend, but that is explicitly prohibited (and documented as such) when using the iptables or nftables backend, so that behavior would need to be changed, especially if the firewalld backend were to become the default under any circumstances).
I would love to have a firewalld backend for libvirt virtual networks, and my to-do list still has "rework egarver's firewalld backend patches", and I keep intending to get back to it, but so far haven't managed to do it. Maybe *next* month :-)
I encourage you to file bugs against libvirt asking for native firewalld support.
I won't say anything against that suggestion, but if Mark isn't using libvirt virtual networks, adding native firewalld support to libvirt won't have any effect on his situation.
The VMs were created libvirt/qemu and are attached to the main system via a Bridge Interface.
IPv6 ping, run traceroute or perform lookups work on the host whether Firewalld is turned on or not.
I have turned firewalld off and all the above functions, seem to work within the VMs. So I am thinking it could be a missing/blocked set of rules that may have not been added to the libvirtd zone or another zone.
Again, unless the config of the guest says "<interface type='network'/> .. <source network='blah'/>", and the libvirt network named 'blah' is of forward mode = nat, route, or none (i.e. no <forward> element in the network definition at all), then libvirt isn't involved in any sort of firewall setup, and the "libvirt" zone is completely irrelevant.
Please be aware that the bridge interface in this scenario is managed by network manager.
Are there any suggestions of any rules to implement to allow?
You'll have to create a policy that allows traffic from the "libvirt" zone to any other zones.
e.g. (untested)
# firewall-cmd --permanent --new-policy libvirtRouted # firewall-cmd --permanent --policy libvirtRouted --add-ingress-zone libvirt # firewall-cmd --permanent --policy libvirtRouted --add-egress-zone ANY # firewall-cmd --permanent --policy libvirtRouted --set-target ACCEPT # firewall-cmd --reload
I'm not sure if you'll need anything else. You may also have to set linux sysctls to enable IPv6 routing.
I have had a look at this guide here (https://superuser.com/questions/1775676/which-inbound-outbound-rules-are-nec...). Although it is Windows based there were 3 things that stood out to me which I believe I may need to get enabled for IPv6 for the VMs.
- ICMPv6
- Neighbor Discovery
- DHCPv6
firewalld allows these for the host side by default. The VMs will be on the libvirt bridge network. ND, etc. are local to the subnet and won't be routed.
This wasn't part of the guide, but would there be a rule needed for this?
- Allowing DNS for IPv6
-- _______________________________________________ firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/firewalld-users@lists.fedorahos... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
https://privatebin.net/?bc9671ee7e81d9df#D2AfL22RVXX1M3kLPYNkUcHb5DUqvFHxdqY... - virsh dumpxml $guestname result.
Yes. The bridge interface was manaully created by me on the host using its network management.
28.01.2025 12:28, Mark Savenent via firewalld-users wrote:
https://privatebin.net/?bc9671ee7e81d9df#D2AfL22RVXX1M3kLPYNkUcHb5DUqvFHxdqY... - virsh dumpxml $guestname result.
It does not tell us anything about your network topology. It only tells us what bridge your guest is plugged into. We have no idea whether traffic via this bridge is bridged, routed, NATed or something else.
On 1/28/25 1:20 PM, Andrei Borzenkov via firewalld-users wrote:
28.01.2025 12:28, Mark Savenent via firewalld-users wrote:
https://privatebin.net/? bc9671ee7e81d9df#D2AfL22RVXX1M3kLPYNkUcHb5DUqvFHxdqYGEUnTTaJB - virsh dumpxml $guestname result.
It does not tell us anything about your network topology. It only tells us what bridge your guest is plugged into. We have no idea whether traffic via this bridge is bridged, routed, NATed or something else.
You are correct, but it *does* tell me what I wanted to learn - it shows that he's not using a libvirt-created bridge and so the problem isn't caused by libvirt's firewall rules, and thus modifying libvirt's firewall rules (either the rules created by libvirt or the rules associated with the "libvirt" firewalld zone) will have 0 effect - the root of the problem is "elsewhere". (i.e. we haven't learned what the problem *is*, but we have learned what it *isn't* :-))
Definitely the next step is to learn what devices are attached to that bridge, as well as the firewalld zone of the bridge device, IP configuration of the host and guest, and possibly the output of "nft list ruleset" or something. But that's someone else's expertise :-)
Routed to the rest of my LAN
Network Toplogy is like this
vnet0 (Interface Member of br0 which the VM uses) > br0 (Manaully Created Bridge) on the OS > enp1f0s1 (Assigned Physical Interface to br0) > Router > Out to the Internet.
Traffic is routed, no use of NAT.
01.02.2025 11:41, Mark Savenent via firewalld-users wrote:
Routed to the rest of my LAN
Network Toplogy is like this
vnet0 (Interface Member of br0 which the VM uses) > br0 (Manaully Created Bridge) on the OS > enp1f0s1 (Assigned Physical Interface to br0) > Router > Out to the Internet.
Traffic is routed, no use of NAT.
No, according to your description it is bridged, not routed. Firewalld should have no impact on it. Show
nft list ruleset
Result of that command here https://privatebin.net/?9411bfe828419d9f#8AmxVSqMTh2bhenRaB8CcPJdRQNKQS1yGws...
01.02.2025 16:07, Mark Savenent via firewalld-users wrote:
Result of that command here https://privatebin.net/?9411bfe828419d9f#8AmxVSqMTh2bhenRaB8CcPJdRQNKQS1yGws...
Anyway - your rules do not match your description. If br0 is connected to the external interface enp1f0s1, you are not supposed to use the external interface enp1f0s1 in any rules. You do not have vmnet0 which is correct - it is below IP level.
So, your configuration is still unclear.
Let me explain this again (as it seems some things are unclear. Although I think I have explained this already. )
There is a bridge interface (br0) I created under the networking tab within Cockpit. I gave it a name of br0.
That bridge has two interface members. See link here (https://ibb.co/Y4Dnr3Sv)
The first is called (enp1s0f1) which br0 uses as interface member. enp1s0f1 on the information I have provided above represents a physical port on my Network Interface Card which connects to a switch that is connected to the rest of my network (in this case a router).
The second member was automatically created when I added (br0) as a network device to my Virtual Machine and it was a TAP device called (vnet0). To do this, I went onto the Virtual Machines tab, clicked on my created VM and scrolled down to the Network interfaces tab. I then clicked add network interface. The interface type I selected was Bridge to LAN with a source of the (br0) with the virtio driver (which can be seen in the images above).
That is the best way i can explain it. Sorry if there has been any confusion.
firewalld-users@lists.fedorahosted.org