|Summary:||firewalld default rule set blocks IPv6 router advertisements|
|Product:||[Fedora] Fedora||Reporter:||Jeff Layton <jlayton>|
|Component:||firewalld||Assignee:||Thomas Woerner <twoerner>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||20||CC:||acathrow, gansalmon, itamar, jonathan, jpirko, jpopelka, kernel-maint, madhu.chinakonda, mgalgoci, nhorman, steved, thaller, twoerner|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-01-31 19:07:53 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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-126.96.36.199-2.fc20.x86_64 libvirt-daemon-driver-storage-188.8.131.52-2.fc20.x86_64 libvirt-gconfig-0.1.7-2.fc20.x86_64 libvirt-client-184.108.40.206-2.fc20.x86_64 libvirt-gobject-0.1.7-2.fc20.x86_64 libvirt-daemon-driver-nwfilter-220.127.116.11-2.fc20.x86_64 libvirt-daemon-driver-network-18.104.22.168-2.fc20.x86_64 libvirt-python-22.214.171.124-2.fc20.x86_64 libvirt-daemon-126.96.36.199-2.fc20.x86_64 libvirt-daemon-kvm-188.8.131.52-2.fc20.x86_64 kernel-3.12.8-300.fc20.x86_64 libvirt-daemon-driver-nodedev-184.108.40.206-2.fc20.x86_64 libvirt-glib-0.1.7-2.fc20.x86_64 libvirt-daemon-driver-secret-220.127.116.11-2.fc20.x86_64 libvirt-daemon-driver-interface-18.104.22.168-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.