[libvirt-users] Getting nwfilter to work on Debian Wheezy

mansheier at gmx.de mansheier at gmx.de
Tue Jul 16 14:09:13 UTC 2013


Am 08.07.2013 16:59, schrieb Sven Schwedas:
> Hi,
>
> I'm trying to configure nwfilter for KVM, but so far I haven't managed
> to figure out a working configuration.
>

I had the same problem.

>
> The linked rules produce the following iptables chains:
>
>> Chain INPUT (policy ACCEPT)
>> target     prot opt source               destination
>> libvirt-host-in  all  --  0.0.0.0/0            0.0.0.0/0
>> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
>> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
>> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:67
>> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:67
>>
>> Chain FORWARD (policy ACCEPT)
>> target     prot opt source               destination
>> libvirt-in  all  --  0.0.0.0/0            0.0.0.0/0
>> libvirt-out  all  --  0.0.0.0/0            0.0.0.0/0
>> libvirt-in-post  all  --  0.0.0.0/0            0.0.0.0/0
>> ACCEPT     all  --  0.0.0.0/0            192.168.128.160/28
>> ACCEPT     all  --  192.168.128.160/28   0.0.0.0/0
>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
>> REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
>> REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
>>
>> Chain OUTPUT (policy ACCEPT)
>> target     prot opt source               destination
>>
>> Chain FI-vnet0 (1 references)
>> target     prot opt source               destination
>> RETURN     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp spt:22 state ESTABLISHED ctdir ORIGINAL
>> RETURN     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp spt:80 state ESTABLISHED ctdir ORIGINAL
>> RETURN     icmp --  0.0.0.0/0            0.0.0.0/0            state NEW,ESTABLISHED ctdir REPLY
>> RETURN     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53 state NEW,ESTABLISHED ctdir REPLY
>> DROP       all  --  0.0.0.0/0            0.0.0.0/0
>>
>> Chain FO-vnet0 (1 references)
>> target     prot opt source               destination
>> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 state NEW,ESTABLISHED ctdir REPLY
>> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80 state NEW,ESTABLISHED ctdir REPLY
>> ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            state ESTABLISHED ctdir ORIGINAL
>> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp spt:53 state ESTABLISHED ctdir ORIGINAL
>> DROP       all  --  0.0.0.0/0            0.0.0.0/0
>>
>> Chain HI-vnet0 (1 references)
>> target     prot opt source               destination
>> RETURN     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp spt:22 state ESTABLISHED ctdir ORIGINAL
>> RETURN     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp spt:80 state ESTABLISHED ctdir ORIGINAL
>> RETURN     icmp --  0.0.0.0/0            0.0.0.0/0            state NEW,ESTABLISHED ctdir REPLY
>> RETURN     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53 state NEW,ESTABLISHED ctdir REPLY
>> DROP       all  --  0.0.0.0/0            0.0.0.0/0
>>
>> Chain libvirt-host-in (1 references)
>> target     prot opt source               destination
>> HI-vnet0   all  --  0.0.0.0/0            0.0.0.0/0           [goto]  PHYSDEV match --physdev-in vnet0
>>
>> Chain libvirt-in (1 references)
>> target     prot opt source               destination
>> FI-vnet0   all  --  0.0.0.0/0            0.0.0.0/0           [goto]  PHYSDEV match --physdev-in vnet0
>>
>> Chain libvirt-in-post (1 references)
>> target     prot opt source               destination
>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in vnet0
>>
>> Chain libvirt-out (1 references)
>> target     prot opt source               destination
>> FO-vnet0   all  --  0.0.0.0/0            0.0.0.0/0           [goto]  PHYSDEV match --physdev-out vnet0
>
> What am  I missing?

In my opinion the network filter rules of libvirt for GNU/Linux do not work.
I tested "libvirt-bin 0.9.8-2ubuntu17.10" and "libvirt-1.1.0" without success.

As you can see in your iptables output above, libvirt creates rules with the target "RETURN" instead of "ACCEPT".

 From the fine manual of iptables:
"RETURN means stop traversing this chain and resume at the next rule in the previous (calling) chain."

Only one new libvirt chain is in the INPUT chain (libvirt-host-in).
The other three libvirt-in, libvirt-out, libvirt-in-post are in the forward chain.
I have no idea what the concept should be.

I inserted the following rules in the INPUT chain _after_ the guest was started and had success:

iptables -I INPUT 1 -j libvirt-out
iptables -I INPUT 1 -j libvirt-in-post
iptables -I INPUT 1 -j libvirt-in
iptables -I INPUT 1 -j libvirt-host-in

If you use the command:
iptables -nvL

instead of just
iptables -nL

you can see the number of packets that arrive in the different chains.
Then you can see that the number of returned packets increases and the packets end up in the chain "libvirt-in-post" which finally ACCEPTs the packets.


To sum it up: file a bug report against libvirt and insert your own iptables rules with -I in the mean time - if you know what you are doing.


Best regards

Hans Meier




More information about the libvirt-users mailing list