virsh cannot start default network due to iptables error

[NotAShelf]

Describe the bug

the default network for libvirtd cannot be started

Steps To Reproduce

Steps to reproduce the behavior:

1. enable firewall using networking.firewall.enable = true;
2. enable libvirtd and qemu using virtualization.libvirtd.enable = true;
3. add your user to the libvirtd group, and relog to apply changes
4. attempt to start the default network using sudo virsh net-start default
5. observe the error:

   $ sudo virsh net-start default
   error: Failed to start network default
   error: internal error: Failed to apply firewall rules /nix/store/6xk3cwvsxnbvbgpsqf78lmaxi2falap4-iptables-1.8.8/bin/iptables -w --table nat --insert POSTROUTING --jump LIBVIRT_PRT: iptables v1.8.8 (nf_tables):  CHAIN_ADD failed (No such file or directory): chain POSTROUTING

Expected behavior

The default network should be started to be used by qemu and virt-manager.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

The chain iptables sees as "missing" is already there.

$  sudo iptables -t nat -L                                             
[sudo] password for notashelf: 
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain LIBVIRT_PRT (0 references)
target     prot opt source               destination 

additionally, a comment on a possibly relevant pull request:

I got network default is not active when start VM. And

sudo virsh net-start default
error: Failed to start network default
error: internal error: Failed to apply firewall rules /nix/store/6lsqk2s082fw0dwcgqg0mg9hgyhv8265-iptables-1.8.7/bin/iptables -w --table nat --insert POSTROUTING --jump LIBVIRT_PRT: iptables v1.8.7 (nf_tables):  CHAIN_ADD failed (No such file or directory): chain POSTROUTING

Is this related? Thanks!

by @linsui

Notify maintainers

@duament - modules/services/networking/firewall-iptables.nix @alexbakker - nixos/modules/virtualisation/libvirtd.nix

Metadata

$ nix-shell -p nix-info --run "nix-info -m" 
 - system: `"x86_64-linux"`
 - host os: `Linux 6.2.8, NixOS, 23.05 (Stoat), 23.05.20230327.4bb072f`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.14.1`
 - nixpkgs: `/nix/store/g738q3jxmym83jx24d422nwc0nas4zyv-source`

[p-rhyme]

Stumbled across this myself recently, you likely enabled security.lockKernelModules which prevented the required modules from being loaded. After doing a diff of the lsmod output when I encountered the error and the lsmod output after disabling module locking I found that the following modules were loaded only when module locking was disabled:

!! Note that in this list I have edac_mce_amd, if you are on an intel platform or perhaps some other cpu architecture you'll probably want to get the list of required modules yourself using the method I described above !!

"evdev" "nf" "nf_nat" "nft_chain_nat" "nf_ct" "xt_conntrack" "nf_conntrack" "xt_CHECKSUM" "xt_MASQUERADE" "ipt_REJECT" "nf_reject_ipv4" "snd_hnd_core" "snd" "udp_diag" "edac_mce_amd" "edac_core" "syscopyarea" "ip6_tables" "vhost" "vhost_net" "vhost_iotlb" "xhci_pci"

Do note that you could shorten this list considerably if you only loaded what you really needed, I used a fedora VM as my test as I had the .iso handy, though if you're doing a more minimal setup (eg. server) you could probably get away with not having some of these loaded. (Though I haven't tested this, so I may also be wrong)

[NotAShelf]

That is a really interesting observation, I'll try that and see how it goes.

Thanks!