Bug 1591017 - nwfilter blocks all network traffic when "clean-traffic" filter is applied to guest interface.
Summary: nwfilter blocks all network traffic when "clean-traffic" filter is applied to...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-13 22:17 UTC by Laine Stump
Modified: 2018-10-30 09:57 UTC (History)
4 users (show)

Fixed In Version: libvirt-4.5.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 09:56:58 UTC
Target Upstream Version:


Attachments (Terms of Use)
Take a look (443 bytes, text/plain)
2018-06-27 07:10 UTC, Maryna Nalbandian
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3113 None None None 2018-10-30 09:57:59 UTC

Description Laine Stump 2018-06-13 22:17:35 UTC
Starting with libvirt 4.1.0, any guest interface that had a "bare" clean-traffic filter added to it:

  <filterref filter='clean-traffic'/>

would not be able to communicate with the network. This was caused by patch d4bf8f415074759baf051644559e04fe78888f8b, pushed upstream between 4.0 and 4.1, which resulted in incomplete ebtables rules being loaded for the guest, with the rules that *were* loaded blocking all traffic to/from the guest.

This was only discovered and fixed after the release of libvirt 4.4.0, by the following commit:

commit 1e49132dde6ae7ec229e3d7550289f9f558ff59b
Author: Daniel P. Berrangé <berrange@redhat.com>
Date:   Fri May 18 12:54:52 2018 +0100

    nwfilter: fix IP address learning

which explains all the details. This patch is upstream and will be included in libvirt 4.5, but would need to be backported to any downstream build of a libvirt between versions 4.1 - 4.4.

Comment 3 yalzhang@redhat.com 2018-06-14 05:11:08 UTC
I can reproduce on libvirt-4.4.0-1.el7.x86_64

1. start a guest with interface as below:
# virsh dumpxml rhel | grep /interface -B8
    <interface type='network'>
      <mac address='52:54:00:f5:10:1e'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <filterref filter='clean-traffic'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/>
    </interface>

2. on guest, run "#dhclient" but it can not get ip address, on host, check the ebtables as below:
# ebtables -t nat -L
Bridge table: nat

Bridge chain: PREROUTING, entries: 2, policy: ACCEPT
-j PREROUTING_direct
-i vnet0 -j libvirt-I-vnet0

Bridge chain: OUTPUT, entries: 1, policy: ACCEPT
-j OUTPUT_direct

Bridge chain: POSTROUTING, entries: 2, policy: ACCEPT
-j POSTROUTING_direct
-o vnet0 -j libvirt-O-vnet0

Bridge chain: PREROUTING_direct, entries: 0, policy: RETURN

Bridge chain: POSTROUTING_direct, entries: 0, policy: RETURN

Bridge chain: OUTPUT_direct, entries: 0, policy: RETURN

Bridge chain: libvirt-I-vnet0, entries: 1, policy: ACCEPT
-j DROP 

Bridge chain: libvirt-O-vnet0, entries: 1, policy: ACCEPT
-j DROP 

The filter will drop all input or output traffic for the guest.

Comment 4 Maryna Nalbandian 2018-06-27 07:10:17 UTC
Created attachment 1454951 [details]
Take a look

Comment 5 Laine Stump 2018-07-01 23:02:49 UTC
Comment on attachment 1454951 [details]
Take a look

This attachment was apparently added to the BZ erroneously, as it isn't related.

Comment 7 yalzhang@redhat.com 2018-07-05 03:13:40 UTC
Test on libvirt-4.5.0-1.el7.x86_64, the result is as expected

1. start a guest with interface as below:
# virsh dumpxml rhelq | grep /interface -B8
    <interface type='network'>
      <mac address='52:54:00:4d:f0:70'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <filterref filter='clean-traffic'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </interface>

2. login guest, check the network works well
# ip a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:4d:f0:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.236/24 brd 192.168.122.255 scope global noprefixroute dynamic eth0
       valid_lft 3499sec preferred_lft 3499sec
    inet6 fe80::5054:ff:fe4d:f070/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

# ping www.baidu.com  -c 2
PING www.a.shifen.com (119.75.213.50) 56(84) bytes of data.
64 bytes from 119.75.213.50 (119.75.213.50): icmp_seq=1 ttl=49 time=2.76 ms
64 bytes from 119.75.213.50 (119.75.213.50): icmp_seq=2 ttl=49 time=15.1 ms

--- www.a.shifen.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 2.762/8.938/15.115/6.177 ms

3. on host, check the ebtables rules, the guest ip address is learned correctly
# ebtables -t nat -L
Bridge table: nat

Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
-i vnet0 -j libvirt-I-vnet0

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
-o vnet0 -j libvirt-O-vnet0

Bridge chain: libvirt-I-vnet0, entries: 9, policy: ACCEPT
-j I-vnet0-mac
-p IPv4 -j I-vnet0-ipv4-ip
-p IPv4 -j ACCEPT 
-p ARP -j I-vnet0-arp-mac
-p ARP -j I-vnet0-arp-ip
-p ARP -j ACCEPT 
-p 0x8035 -j I-vnet0-rarp
-p 0x835 -j ACCEPT 
-j DROP 

Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT
-p IPv4 -j O-vnet0-ipv4
-p ARP -j ACCEPT 
-p 0x8035 -j O-vnet0-rarp
-j DROP 

Bridge chain: I-vnet0-mac, entries: 2, policy: ACCEPT
-s 52:54:0:4d:f0:70 -j RETURN 
-j DROP 

Bridge chain: I-vnet0-ipv4-ip, entries: 3, policy: ACCEPT
-p IPv4 --ip-src 0.0.0.0 --ip-proto udp -j RETURN 
-p IPv4 --ip-src 192.168.122.236 -j RETURN 
-j DROP 

Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT
-j ACCEPT 

Bridge chain: I-vnet0-arp-mac, entries: 2, policy: ACCEPT
-p ARP --arp-mac-src 52:54:0:4d:f0:70 -j RETURN 
-j DROP 

Bridge chain: I-vnet0-arp-ip, entries: 2, policy: ACCEPT
-p ARP --arp-ip-src 192.168.122.236 -j RETURN 
-j DROP 

Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT
-p 0x8035 -s 52:54:0:4d:f0:70 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:4d:f0:70 --arp-mac-dst 52:54:0:4d:f0:70 -j ACCEPT 
-j DROP 

Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT
-p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:4d:f0:70 --arp-mac-dst 52:54:0:4d:f0:70 -j ACCEPT 
-j DROP

Comment 8 yalzhang@redhat.com 2018-07-06 06:00:58 UTC
Hi lanie, there is a bug about nwfilter and I think it may related with recent nwfilter changes. Could you please help to check? Thank you!
Bug 1598311 - Error message is weird when there is no enough pci slot for hotplug interface

Comment 10 errata-xmlrpc 2018-10-30 09:56:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3113


Note You need to log in before you can comment on or make changes to this bug.