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 1058505 - Update to hosed IPv6
Summary: Update to hosed IPv6
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
: 1059789 (view as bug list)
Depends On:
Blocks: 1067652
TreeView+ depends on / blocked
Reported: 2014-01-27 22:45 UTC by Pete Zaitcev
Modified: 2014-02-20 19:58 UTC (History)
4 users (show)

Fixed In Version: firewalld-
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1067652 (view as bug list)
Last Closed: 2014-02-11 23:02:42 UTC

Attachments (Terms of Use)

Description Pete Zaitcev 2014-01-27 22:45:17 UTC
Description of problem:

After yum update, IPv6 address is no longer set on the interface.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

0. have a network with IPv6
1. Install F20 GA
2. install ndisc6
3. run  rdisc6 p4p1   # or eth0 forsystems upgraded from F18
4. yum update firewalld
5. run rdisc6 and verify that it times out

Actual results:

ipv6 is not configured

Expected results:

ipv6 configured

Additional info:

One could just reboot and verify that there's no address, but
rdisc6 test demonstrate clearly that NetworkManager are
not the culprit.

Last known good version is firewalld-0.3.8-1.fc20.noarch.
This is verified by downgrading with rpm -U --oldpackage.

Comment 1 Jiri Popelka 2014-01-29 16:40:02 UTC
I can (sort of) confirm that.

After reboot I don't have any IPv6 address and 'rdisc6 em1' times out.
After stopping firewalld 'rdisc6 em1' gets reply and IPv6 is there.

However if I now start firewalld and try 'rdisc6 em1' I'm still getting replies, how come ?

Comment 2 Pete Zaitcev 2014-01-29 17:18:18 UTC
It's even better. I compared the tables between the working and non-working
systems and they seem generally the same. V.mysterious.

Comment 3 Jiri Popelka 2014-01-30 15:18:42 UTC
1. reboot
2. machine doesn't accept any icmpv6, i.e. Router Advertisements or echo requests (ping6)
3. systemctl restart firewalld
4. machine receives RAs (i.e. auto-sets ipv6 address) and echo requests (i.e. replies to ping6)
5. diff of ip6tables-save before and after step 3 shows *no* difference

And to make it worse I can reproduce it on bare metal, but not in virtual machine (where everything's fine even after boot).

Comment 4 Jiri Popelka 2014-01-31 12:48:38 UTC
Pete, can you set 'IPv6_rpfilter=no' in /etc/firewalld/firewalld.conf and try to reproduce it ?

With IPv6_rpfilter=yes (by default) we do
-t raw -I PREROUTING 1 -m rpfilter --invert -j DROP
which seems to DROP all the ICMPv6 packets.

We added this in 0.3.9 due to bug #847707 and we should disable it by default until we find what's the problem with it.

Comment 5 Pete Zaitcev 2014-01-31 18:12:56 UTC
Confirmed that setting IPv6_rpfilter=no works around the issue per
Jiri's comment #4. After reboot, IPv6 address is acquired.

[root@lembas zaitcev]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:22:68:14:e9:91 brd ff:ff:ff:ff:ff:ff
    inet brd scope global dynamic eth0
       valid_lft 42042sec preferred_lft 42042sec
    inet6 fd2d:acfb:74cc:1:222:68ff:fe14:e991/64 scope global dynamic 
       valid_lft 86386sec preferred_lft 14386sec
    inet6 fe80::222:68ff:fe14:e991/64 scope link 
       valid_lft forever preferred_lft forever
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:1e:65:cf:3c:10 brd ff:ff:ff:ff:ff:ff
[root@lembas zaitcev]# rpm -q firewalld
[root@lembas zaitcev]#

Comment 6 Jeff Layton 2014-01-31 19:07:53 UTC
*** Bug 1059789 has been marked as a duplicate of this bug. ***

Comment 7 Jeff Layton 2014-01-31 19:09:04 UTC
FWIW, I hit the same problem, and ended up adding a passthrough rule as a workaround:

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

Haven't tried disabling rpfilter yet though.

Comment 8 Jeff Layton 2014-01-31 19:17:18 UTC
Confirmed that disabling rpfilter also fixes it.

Comment 9 Florian Weimer 2014-02-05 09:09:38 UTC
How harmful can processing router advertisements be? After peaking at the kernel code, I believe it will accept more specific prefixes for existing routes (and it probably has to), so router advertisements could be used to redirect traffic out of VPN tunnels, affecting firewalld zone separation.

To some degree, IPv4 is affected as well, particularly when using ISC's DHCP client with typical callback scripts:

So unless I'm missing some really bad aspect of router advertisements, accepting them is probably okay.

Comment 10 Fedora Update System 2014-02-05 17:10:01 UTC
firewalld- has been submitted as an update for Fedora 20.

Comment 11 Fedora Update System 2014-02-07 03:04:51 UTC
Package firewalld-
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing firewalld-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2014-02-11 23:02:42 UTC
firewalld- has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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