Hi, let us ensure we understand what exactly you mean and then we can see if that is an issue in the packaging, an issue in the upstream project or sadly just works as intended.
Libvirt defines a bunch of it's own rulesets depending on its configuration. The following is the one you'd get by default. Chain LIBVIRT_FWI (1 references) target prot opt source destination ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain LIBVIRT_FWO (1 references) target prot opt source destination ACCEPT all -- 192.168.122.0/24 anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain LIBVIRT_FWX (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain LIBVIRT_INP (1 references) target prot opt source destination ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:bootps ACCEPT tcp -- anywhere anywhere tcp dpt:67 Chain LIBVIRT_OUT (1 references) target prot opt source destination ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:bootpc ACCEPT tcp -- anywhere anywhere tcp dpt:68 These it then inserts as rules into the default chains. Chain INPUT (policy ACCEPT) target prot opt source destination LIBVIRT_INP all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination LIBVIRT_FWX all -- anywhere anywhere LIBVIRT_FWI all -- anywhere anywhere LIBVIRT_FWO all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination LIBVIRT_OUT all -- anywhere anywhere I assume you have a conflict with e.g. the LIBVIRT_FWO rule ending rejecting all else. Please confirm and share what else you have set up for the hotspot that is in conflict with it. Libvirt does indeed re-populate rules on any reload. You mentioned some package installs, but I assume a package upgrade, reinstall or a service restart would do the same. This isn't new, the topic (If I identified it right) has been discussed for at least a decade - https://serverfault.com/questions/565871/libvirt-and-network-filtering-with-nat-iptables-overrides - https://stackoverflow.com/questions/30654803/libvirt-iptables-rules-disrupt-port-forwarding-to-my-kvm-vms In a similar fashion there are conflicts with other things as well, for example: https://serverfault.com/questions/963759/docker-breaks-libvirt- bridge-network I think, the comfort for all to work out of the box comes to a challenge here and one would likely need to fall back on configuring the birdges themselve. I feel there must be a better discussion or issue tracker in upstream libvirt, but I couldn't find it :-/ For now I think this is sadly "works as designed, please manually configure your bridges and tell libvirt (and others like the docker example) to leave them alone" :-/ I do not see something actionable but would be curious to learn the rest of the case - maybe my assumptions are wrong? ** Changed in: libvirt (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2111633 Title: KVM hotspot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/2111633/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
