Likely a duplicate of bug#1226105. Do you have iptables-nft installed? See comment #9 in that bug for details, and a workaround

https://bugzilla.suse.com/show_bug.cgi?id=1226105#c9

I do not have `iptables-nft` installed.

```
$ zypper se -i '/(nf|ip)tables.*/'
Loading repository data...
Reading installed packages...

S | Name               | Summary                                                 | Type
--+--------------------+---------------------------------------------------------+--------
i | iptables           | IP packet filter administration utilities               | package
i | libnftables1       | nftables firewalling command interface                  | package
i | nftables           | Userspace utility to access the nf_tables packet filter | package
i | python311-nftables | Python bindings for nftables                            | package
```

(In reply to Anchal Nigam from comment #2)
> I do not have `iptables-nft` installed.

I'll stop commenting in that forums thread and handle your issue here :-). But it was good to describe the problem there and give pointers to workaround and further reading. BTW, did you try the workaround? I.e. set

firewall_backend = "iptables"

in /etc/libvirt/network.conf and restart virtnetworkd?

Before doing that, provide the output of 'nft list ruleset ip'. We can check if there are any top-level tables with rules that conflict with rules in libvirt's tables.

`nft list ruleset ip` returns nothing.

```
desk:/ # nft list ruleset ip
desk:/ # 
```

Should I still try setting `firewall_backend = "iptables"`? The way I read it, it sounded like I would only do that if I have iptables-nft or nft rules. 

I don't fully understand what any of this means.

(In reply to Anchal Nigam from comment #4)
> desk:/ # nft list ruleset ip
> desk:/ # 

Interesting. That really implies you don't have virtnetworkd running or the default network active. What is output of 'systemctl status virtnetworkd' and 'virsh net-list'?

My default network is active according to virt-manager.

```
desk:/ # systemctl status virtnetworkd
● virtnetworkd.service - libvirt network daemon
     Loaded: loaded (/usr/lib/systemd/system/virtnetworkd.service; disabled; preset: disabled)
     Active: active (running) since Fri 2024-06-21 17:08:56 EDT; 1min 6s ago
TriggeredBy: ● virtnetworkd-admin.socket
             ● virtnetworkd.socket
             ● virtnetworkd-ro.socket
       Docs: man:virtnetworkd(8)
             https://libvirt.org/
   Main PID: 18888 (virtnetworkd)
      Tasks: 21 (limit: 4915)
        CPU: 180ms
     CGroup: /system.slice/virtnetworkd.service
             ├─18888 /usr/sbin/virtnetworkd --timeout 120
             ├─18965 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
             └─18966 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper

Jun 21 17:08:56 desk systemd[1]: Started libvirt network daemon.
Jun 21 17:08:57 desk dnsmasq[18965]: started, version 2.90 cachesize 2000
Jun 21 17:08:57 desk dnsmasq[18965]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 Lua TFTP conntrack ipset no-nftset auth cryptohash DNSSEC loop-dete>
Jun 21 17:08:57 desk dnsmasq-dhcp[18965]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h
Jun 21 17:08:57 desk dnsmasq-dhcp[18965]: DHCP, sockets bound exclusively to interface virbr0
Jun 21 17:08:57 desk dnsmasq[18965]: reading /etc/resolv.conf
Jun 21 17:08:57 desk dnsmasq[18965]: using nameserver 192.168.10.1#53
Jun 21 17:08:57 desk dnsmasq[18965]: read /etc/hosts - 11 names
Jun 21 17:08:57 desk dnsmasq[18965]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 names
Jun 21 17:08:57 desk dnsmasq-dhcp[18965]: read /var/lib/libvirt/dnsmasq/default.hostsfile
desk:/ # 
desk:/ # virsh net-list
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

desk:/ # 
```

Is this a regression? Did it work for you before? Does the Windows VM have virtio drivers installed?

> Is this a regression? Did it work for you before? Does the Windows VM have virtio drivers installed?

No. This is a fresh install of OS TW with KVM selected during install, and then Docker after I was up and running.

The Windows VM does have the virtio drivers installed. The VM was from when I was running Debian -- I copied the qcow2 file.

I will try creating a new VM to see if the new VM has the same issue.

(In reply to Anchal Nigam from comment #8)
> > Is this a regression? Did it work for you before? Does the Windows VM have virtio drivers installed?
> 
> No. This is a fresh install of OS TW with KVM selected during install, and
> then Docker after I was up and running.

Do you see the issue without Docker installed?

> The Windows VM does have the virtio drivers installed. The VM was from when
> I was running Debian -- I copied the qcow2 file.

I suppose the VM has community virtio drivers, which AFAIK should would fine. Kirk as more experience with Windows drivers for virtual devices. He develops/maintains the various Windows drivers within the Virtual Machine Driver Pack (VMDP).

> I will try creating a new VM to see if the new VM has the same issue.

Thanks, this would be a good test as well. Configuring the VM to use an emulated NIC such as e1000 and avoiding virtio would be another interesting test.

(In reply to James Fehlig from comment #9)
> Do you see the issue without Docker installed?

I will have to uninstall it and check.

> Thanks, this would be a good test as well. Configuring the VM to use an
> emulated NIC such as e1000 and avoiding virtio would be another interesting
> test.

Will try these combinations before I install Docker.

(In reply to Anchal Nigam from comment #10)
> (In reply to James Fehlig from comment #9)
> > Do you see the issue without Docker installed?
> 
> I will have to uninstall it and check.
> 
> > Thanks, this would be a good test as well. Configuring the VM to use an
> > emulated NIC such as e1000 and avoiding virtio would be another interesting
> > test.
> 
> Will try these combinations before I install Docker.

Hi! Have you had an opportunity to try without docker? And try creating a new VM that uses an emulated NIC?

(In reply to James Fehlig from comment #11)
> Hi! Have you had an opportunity to try without docker? And try creating a
> new VM that uses an emulated NIC?

Unfortunately not yet. I was mucking around with something and screwed up my entire computer. I have to do a fresh install and will check then. But it'll take a while.