Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1059789 - firewalld default rule set blocks IPv6 router advertisements
Summary: firewalld default rule set blocks IPv6 router advertisements
Keywords:
Status: CLOSED DUPLICATE of bug 1058505
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: 20
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-30 16:20 UTC by Jeff Layton
Modified: 2014-06-18 07:43 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-31 19:07:53 UTC


Attachments (Terms of Use)
XML config for virtual bridge network (deleted)
2014-01-30 16:21 UTC, Jeff Layton
no flags Details

Description Jeff Layton 2014-01-30 16:20:16 UTC
I have RHEL6 running on a bare-metal box that acts as a KVM host. That host gets an IPv6 address via router advertisements. libvirtd is set up to add a virtual bridge interface for the guests to communicate with one another and the host (virbr0).

When I boot up the box, the main ethernet interface fails to autoconfigure its IPv6 address. If I remove the virbr0 interface from the configuration then it works. So, something in how libvirtd in how libvirtd is configuring this network is causing the main ethernet interface on the box to fail to autoconfigure.

The machine is fully patched 6.5.z host with a more recent kernel, which I was playing with trying to get this to work:

    libvirt-0.10.2-29.el6_5.3.x86_64
    kernel-2.6.32-441.el6.x86_64

default.xml virtual network config is attached.

Comment 1 Jeff Layton 2014-01-30 16:21:23 UTC
Created attachment 857562 [details]
XML config for virtual bridge network

Comment 2 Jeff Layton 2014-01-30 16:34:14 UTC
Also, to narrow it down a bit. The virbr0 network is not problematic if I remove this line:

  <forward mode='nat'/>

...so the problem may be in how the firewall rules are being set?

Comment 3 Jeff Layton 2014-01-30 16:55:26 UTC
Actually, I take that back. I added that back in and it's still working. There doesn't seem to be a lot of rhyme or reason to why this works sometimes and not at others.

I suspect that there may be some timing involved.

One more hint. If I start the box up with libvirtd chkconfig'ed on, but with the virbr0 network disabled, I get a properly configured eth0 and can ping other addresses:

PING 2620:52:0:1065:216:36ff:fe79:28fb(2620:52:0:1065:216:36ff:fe79:28fb) 56 data bytes
64 bytes from 2620:52:0:1065:216:36ff:fe79:28fb: icmp_seq=1 ttl=59 time=21.6 ms
64 bytes from 2620:52:0:1065:216:36ff:fe79:28fb: icmp_seq=2 ttl=59 time=19.2 ms

...if I then go and start up virbr0 with the forwarding directive in place:

[jlayton@sikun ~]$ ping6 2620:52:0:1065:216:36ff:fe79:28fb
PING 2620:52:0:1065:216:36ff:fe79:28fb(2620:52:0:1065:216:36ff:fe79:28fb) 56 data bytes
^C
--- 2620:52:0:1065:216:36ff:fe79:28fb ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9469ms

...then it seems to break the routing. Routing table looks fine however:

$ ip6 route show
2620:52:0:800::/64 dev eth0  proto kernel  metric 256  expires 2590985sec mtu 1500 advmss 1440 hoplimit 4294967295
fd84:87d:d3d5:c5c0::/64 dev virbr0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev usb0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev virbr0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
default via fe80:52:0:800::1ffe dev eth0  proto static  metric 1  mtu 1500 advmss 1440 hoplimit 4294967295
default via fe80:52:0:800::1ffe dev eth0  proto kernel  metric 1024  expires 1572sec mtu 1500 advmss 1440 hoplimit 64

...if I then "stop" the virbr0 network, pinging external hosts works fine again.

Comment 4 Jeff Layton 2014-01-30 17:21:23 UTC
ping6 works however if I do this:

$ ping6 -I 2620:52:0:800:3640:b5ff:fe8c:5270 2620:52:0:1065:216:36ff:fe79:28fb

So it seems like ping6 is just picking the wrong source address to use.

...at this point, I'm just thoroughly confused. ;)

Comment 5 Jeff Layton 2014-01-31 11:34:07 UTC
For other reasons I had to move this box to f20, and have found that it has the exact same issue. So moving this to Fedora for now and we can look at backporting to RHEL once it's fixed.

Given that stateless autoconfig is done in the kernel, I'm also going to move this to a kernel bug.

Comment 6 Jeff Layton 2014-01-31 11:40:39 UTC
So to summarize -- current relevant packages are:

$ rpm -qa kernel libvirt\*
libvirt-daemon-driver-qemu-1.1.3.3-2.fc20.x86_64
libvirt-daemon-driver-storage-1.1.3.3-2.fc20.x86_64
libvirt-gconfig-0.1.7-2.fc20.x86_64
libvirt-client-1.1.3.3-2.fc20.x86_64
libvirt-gobject-0.1.7-2.fc20.x86_64
libvirt-daemon-driver-nwfilter-1.1.3.3-2.fc20.x86_64
libvirt-daemon-driver-network-1.1.3.3-2.fc20.x86_64
libvirt-python-1.1.3.3-2.fc20.x86_64
libvirt-daemon-1.1.3.3-2.fc20.x86_64
libvirt-daemon-kvm-1.1.3.3-2.fc20.x86_64
kernel-3.12.8-300.fc20.x86_64
libvirt-daemon-driver-nodedev-1.1.3.3-2.fc20.x86_64
libvirt-glib-0.1.7-2.fc20.x86_64
libvirt-daemon-driver-secret-1.1.3.3-2.fc20.x86_64
libvirt-daemon-driver-interface-1.1.3.3-2.fc20.x86_64

The ethernet interface is coming up now as enp6s0:

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.8.0.43  netmask 255.255.224.0  broadcast 10.8.31.255
        inet6 fe80::3640:b5ff:fe8c:5270  prefixlen 64  scopeid 0x20<link>
        ether 34:40:b5:8c:52:70  txqueuelen 1000  (Ethernet)
        RX packets 362184  bytes 132713144 (126.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 95468  bytes 81364829 (77.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  memory 0xc1a80000-c1aa0000  


...it should be getting a global scope ipv6 address via RA broadcast, but isn't. I also have this bridge being set up via libvirt:

virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        inet6 fe80::5054:ff:fe6c:d8ed  prefixlen 64  scopeid 0x20<link>
        inet6 fd84:87d:d3d5:c5c0::1  prefixlen 64  scopeid 0x0<global>
        ether 52:54:00:6c:d8:ed  txqueuelen 0  (Ethernet)
        RX packets 2021653  bytes 2251379506 (2.0 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1634503  bytes 2469311857 (2.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


None of the interfaces are incrementing the router advert counters:

$ grep Icmp6InRouterAdvertisements /proc/net/dev_snmp6/*
/proc/net/dev_snmp6/enp0s29u1u1u5:Icmp6InRouterAdvertisements     	0
/proc/net/dev_snmp6/enp11s0:Icmp6InRouterAdvertisements     	0
/proc/net/dev_snmp6/enp6s0:Icmp6InRouterAdvertisements     	0
/proc/net/dev_snmp6/lo:Icmp6InRouterAdvertisements     	0
/proc/net/dev_snmp6/virbr0:Icmp6InRouterAdvertisements     	0
/proc/net/dev_snmp6/virbr0-nic:Icmp6InRouterAdvertisements     	0
/proc/net/dev_snmp6/vnet0:Icmp6InRouterAdvertisements     	0
/proc/net/dev_snmp6/vnet1:Icmp6InRouterAdvertisements     	0
/proc/net/dev_snmp6/vnet2:Icmp6InRouterAdvertisements     	0

...but if I sniff traffic on enp6s0, I can see them coming in.

Comment 7 Jeff Layton 2014-01-31 11:54:47 UTC
Also, I decided to try shutting down virb0 and disabling firewalld after the box comes up. So now, iptables, ip6tables and ebtables all show empty rule sets and there is no virbr0 configured at all.

I then did a "systemctl restart NetworkManager", and ifdown/ifup enp6s0. I still don't get a global ipv6 address and I don't see Icmp6InRouterAdvertisements incrementing past 0.

FWIW:

$ ls /proc/sys/net/ipv6/conf/enp6s0/a* |
> while read procfile
> do
> echo -n "$procfile: "
> cat $procfile
> done
/proc/sys/net/ipv6/conf/enp6s0/accept_dad: 1
/proc/sys/net/ipv6/conf/enp6s0/accept_ra: 1
/proc/sys/net/ipv6/conf/enp6s0/accept_ra_defrtr: 1
/proc/sys/net/ipv6/conf/enp6s0/accept_ra_pinfo: 1
/proc/sys/net/ipv6/conf/enp6s0/accept_ra_rt_info_max_plen: 0
/proc/sys/net/ipv6/conf/enp6s0/accept_ra_rtr_pref: 1
/proc/sys/net/ipv6/conf/enp6s0/accept_redirects: 1
/proc/sys/net/ipv6/conf/enp6s0/accept_source_route: 0
/proc/sys/net/ipv6/conf/enp6s0/autoconf: 1

If there are other entries below there that would be helpful, then let me know...

Comment 8 Jeff Layton 2014-01-31 12:05:23 UTC
Hmm...after those changes, I now see InRouterAdv going upward:

$ grep Router /proc/net/dev_snmp6/enp6s0 
Icmp6InRouterSolicits           	91
Icmp6InRouterAdvertisements     	2
Icmp6OutRouterSolicits          	1
Icmp6OutRouterAdvertisements    	0

...but the interface still isn't autoconfiguring itself. I wouldn't think that it should give up on autoconfiguration so it seems like maybe the bridge configuration did something that broke it?

Comment 9 Jeff Layton 2014-01-31 13:26:34 UTC
As of this morning, I can generally get an address if I disable firewalld and reboot. If I enable it and reboot -- no address.

That seems like it's probably something in the firewall config, but the behavior on this is really hard to pin down...

Comment 11 Jeff Layton 2014-01-31 18:22:15 UTC
Ok, I think I've figured out what's wrong. Specifically, the problem is caused by rule #1 in the ipv6 raw table:

Chain PREROUTING (policy ACCEPT 127 packets, 10552 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       65  5272 DROP       all      *      *       ::/0                 ::/0                 rpfilter invert
2      127 10552 PREROUTING_direct  all      *      *       ::/0                 ::/0                

...when I remove that rule, the autoconfigured address pops up as soon as the next RA comes in.

Comment 12 Jeff Layton 2014-01-31 18:37:37 UTC
FWIW, I added a passthrough config rule as a workaround:

  <passthrough ipv="ipv6">-t raw -I PREROUTING 1 -p icmpv6 --icmpv6-type=router-advertisement -j ACCEPT</passthrough>


It does seem odd however and maybe this is still a kernel bug. It seems like the ip6tables rpfilter code ought not filter out things that come in from link-local addresses, right? OTOH, I'm sure exactly why it's being rejected, but that definitely warrants some scrutiny.

Comment 13 Jiri Popelka 2014-01-31 18:50:28 UTC
Looks like duplicate of bug #1058505

Comment 14 Jeff Layton 2014-01-31 19:07:53 UTC
Yep, good call. Closing as a dup of that bug.

*** This bug has been marked as a duplicate of bug 1058505 ***


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