9:59 a.m.
Hi,
I'm trying to configure nwfilter for KVM, but so far I haven't managed
to figure out a working configuration.
Network setup: The dom0 (Debian 7.1, kernel 3.2.46-1, libvirt 0.9.12) is
connected via eth0, part of the external subnet 192.168.17.0/24, and has
an additional subnet 192.168.128.160/28 routed to its main address
192.168.17.125.
The host's subnet is configured as bridge in virsh:
<network>
<name>foo</name>
<forward dev='eth0' mode='route'>
<interface dev='eth0'/>
</forward>
<bridge name='foo-br0' stp='off' delay='0' />
<ip address='192.168.128.161' netmask='255.255.255.240'>
</ip>
</network>
The domU is configured to use this bridge (static IP configured in DomU):
<interface type='network'>
<source network='foo'/>
<target dev='vnet0'/>
<model type='virtio'/>
<filterref filter='test-eth0'>
<parameter name='CTRL_IP_LEARNING' value='none'/>
<parameter name='IP' value='192.168.128.162'/>
</filterref>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
With an empty filter, connectivity is working fine. Now, if I add the
example ruleset suggested in the documentation (
http://libvirt.org/formatnwfilter.html#nwfwriteexample ), *incoming*
ICMP works (but not outgoing), and inbound SSH traffic is blocked,
together with outbound DNS.
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
I've tried fidgeting with the configuration (direction inout instead of
in/out, etc.), but I didn't find a setup that works as intended. What am
I missing?
--
Mit freundlichen Grüßen, / Best Regards,
Sven SCHWEDAS
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwedas(a)tao.at | +43 (0)680 301 7167
http://software.tao.at
4:34 a.m.
New subject: [libvirt-users] The firewall just doesn't make any sense
Okay, some more fiddling:
If I try the second filterset from the second example from the
documentation (
http://libvirt.org/formatnwfilter.html#nwfwriteexample2nd
), the resulting firewall rules make even less sense.
To quote, what it should do:
opens only TCP ports 22 and 80 of a VM's interface
allows the VM to send ping traffic from an interface but not let the VM be pinged on the
interface
allows the VM to do DNS lookups (UDP towards port 53)
enable an ftp server (in active mode) to be run inside the VM
What it does:
Opens all incoming ports
Allows the VM to be pinged
Blocks all outgoing traffic (except ICMP, but I suspect that's only
because ICMP filtering does not work at all, see above)
Prevents an ftp server from running in active mode
This is bullshit. How do I get the nwfilter firewall to run properly?
--
Mit freundlichen Grüßen, / Best Regards,
Sven SCHWEDAS
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwedas(a)tao.at | +43 (0)680 301 7167
http://software.tao.at
3:44 a.m.
On 11.07.2013 03:24, Gao Yongwei wrote:
I always use ebtables instead of iptables and everything works fine for me.
ebtables works with mac stp vlan arp rarp ipv4 ipv6 , tcp udp works with
iptables.
ebtables does not seem to support stateful filtering, making it a poor
replacement.
Surely there has to be a way to make nwfilter work as documented?
--
Mit freundlichen Grüßen, / Best Regards,
Sven SCHWEDAS
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwedas(a)tao.at | +43 (0)680 301 7167
http://software.tao.at
5:52 a.m.
New subject: [libvirt-users] The firewall just doesn't make any sense
Could *somebody* shed some light on how the firewall is supposed to
work? I haven't even managed to get trivial firewall rules to work. As
mentioned, the examples in the documentation generate completely
nonsensical rulesets, and if I try writing my own, they make even less
sense.
For example:
<filter name='test-eth0' chain='root'>
<rule action='drop' direction='in' priority='900'>
<all state='NEW'/>
</rule>
</filter>
Generates the following iptables rules: https://up.tao.at/u/DE7E2638.txt
...and will not filter anything.
<filter name='test-eth0' chain='root'>
<rule action='accept' direction='in' priority='500'>
<tcp srcipaddr='192.168.17.127' dstportstart='22'/>
</rule>
<rule action='drop' direction='in' priority='900'>
<all/>
</rule>
</filter>
Will filter port 22 as well. The generated iptables rules are as
following: https://up.tao.at/u/423CFFE9.txt
The *input* rules have the *source* address set as *destination*. Is
this a bug in libvirt/iptables?
--
Mit freundlichen Grüßen, / Best Regards,
Sven SCHWEDAS
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwedas(a)tao.at | +43 (0)680 301 7167
http://software.tao.at
5:57 a.m.
New subject: [libvirt-users] The firewall just doesn't make any sense
On Mon, Jul 15, 2013 at 12:52:20PM +0200, Sven Schwedas wrote:
Could *somebody* shed some light on how the firewall is supposed to
work? I haven't even managed to get trivial firewall rules to work. As
mentioned, the examples in the documentation generate completely
nonsensical rulesets, and if I try writing my own, they make even less
sense.
For example:
> <filter name='test-eth0' chain='root'>
> <rule action='drop' direction='in' priority='900'>
> <all state='NEW'/>
> </rule>
> </filter>
Generates the following iptables rules: https://up.tao.at/u/DE7E2638.txt
...and will not filter anything.
NB 95% of the rules libvirt creates are done at the ebtables
level rather than iptables/ip6tables.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
7:59 a.m.
New subject: [libvirt-users] The firewall just doesn't make any sense
On 15.07.2013 12:57, Daniel P. Berrange wrote:
On Mon, Jul 15, 2013 at 12:52:20PM +0200, Sven Schwedas wrote:
> Could *somebody* shed some light on how the firewall is supposed to
> work? I haven't even managed to get trivial firewall rules to work. As
> mentioned, the examples in the documentation generate completely
> nonsensical rulesets, and if I try writing my own, they make even less
> sense.
>
> For example:
>> <filter name='test-eth0' chain='root'>
>> <rule action='drop' direction='in'
priority='900'>
>> <all state='NEW'/>
>> </rule>
>> </filter>
>
> Generates the following iptables rules: https://up.tao.at/u/DE7E2638.txt
>
> ...and will not filter anything.
NB 95% of the rules libvirt creates are done at the ebtables
level rather than iptables/ip6tables.
Said filter set did not generate any ebtables entries. Complete output
for ip- and ebtables: https://up.tao.at/u/17C4B040.txt
Daniel
--
Mit freundlichen Grüßen, / Best Regards,
Sven SCHWEDAS
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwedas(a)tao.at | +43 (0)680 301 7167
http://software.tao.at
8:24 p.m.
2013/7/8 Sven Schwedas <sven.schwedas(a)tao.at>
Hi,
I'm trying to configure nwfilter for KVM, but so far I haven't managed
to figure out a working configuration.
Network setup: The dom0 (Debian 7.1, kernel 3.2.46-1, libvirt 0.9.12) is
connected via eth0, part of the external subnet 192.168.17.0/24, and has
an additional subnet 192.168.128.160/28 routed to its main address
192.168.17.125.
The host's subnet is configured as bridge in virsh:
> <network>
> <name>foo</name>
> <forward dev='eth0' mode='route'>
> <interface dev='eth0'/>
> </forward>
> <bridge name='foo-br0' stp='off' delay='0' />
> <ip address='192.168.128.161' netmask='255.255.255.240'>
> </ip>
> </network>
The domU is configured to use this bridge (static IP configured in DomU):
> <interface type='network'>
> <source network='foo'/>
> <target dev='vnet0'/>
> <model type='virtio'/>
> <filterref filter='test-eth0'>
> <parameter name='CTRL_IP_LEARNING' value='none'/>
> <parameter name='IP' value='192.168.128.162'/>
> </filterref>
> <alias name='net0'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x03'
function='0x0'/>
> </interface>
With an empty filter, connectivity is working fine. Now, if I add the
example ruleset suggested in the documentation (
http://libvirt.org/formatnwfilter.html#nwfwriteexample ), *incoming*
ICMP works (but not outgoing), and inbound SSH traffic is blocked,
together with outbound DNS.
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
I've tried fidgeting with the configuration (direction inout instead of
in/out, etc.), but I didn't find a setup that works as intended. What am
I missing?
I always use ebtables instead of iptables and everything works fine for me.
ebtables works with mac stp vlan arp rarp ipv4 ipv6 , tcp udp works with
iptables.
9:09 a.m.
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
6:04 a.m.
On 07/08/2013 10:59 AM, Sven Schwedas wrote:
Hi,
I'm trying to configure nwfilter for KVM, but so far I haven't managed
to figure out a working configuration.
Network setup: The dom0 (Debian 7.1, kernel 3.2.46-1, libvirt 0.9.12) is
connected via eth0, part of the external subnet 192.168.17.0/24, and has
an additional subnet 192.168.128.160/28 routed to its main address
192.168.17.125.
The host's subnet is configured as bridge in virsh:
> <network>
> <name>foo</name>
> <forward dev='eth0' mode='route'>
> <interface dev='eth0'/>
> </forward>
> <bridge name='foo-br0' stp='off' delay='0' />
> <ip address='192.168.128.161' netmask='255.255.255.240'>
> </ip>
> </network>
The domU is configured to use this bridge (static IP configured in DomU):
> <interface type='network'>
> <source network='foo'/>
> <target dev='vnet0'/>
> <model type='virtio'/>
> <filterref filter='test-eth0'>
> <parameter name='CTRL_IP_LEARNING' value='none'/>
> <parameter name='IP' value='192.168.128.162'/>
> </filterref>
> <alias name='net0'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
> </interface>
With an empty filter, connectivity is working fine. Now, if I add the
example ruleset suggested in the documentation (
http://libvirt.org/formatnwfilter.html#nwfwriteexample ), *incoming*
ICMP works (but not outgoing), and inbound SSH traffic is blocked,
together with outbound DNS.
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
I've tried fidgeting with the configuration (direction inout instead of
in/out, etc.), but I didn't find a setup that works as intended. What am
I missing?
Depending on the settings of your Linux distribution you may need to
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
to enable iptables filtering for traffic traversing the bridge. Does
this get it to work?
Stefan
4007
days inactive
4036
days old
8 comments
5 participants
participants (5)
-
Daniel P. Berrange -
Gao Yongwei -
mansheier＠gmx.de -
Stefan Berger -
Sven Schwedas