Red Hat Bugzilla – Bug 805405
NM adds device to firewall zone after successful activation, causing a DHCPv6 catch-22
Last modified: 2012-03-23 13:43:20 EDT
Description of problem:
Adding this to bugzilla at the request of adamw so that it can block #752649.
NM currently add interface to a firewall zone only *after* successful activation of the interface in question. This causes a catch-22 when DHCPv6 is used on the network, because DHCPv6 won't be allowed through the firewall before the interface is added to a zone, but since DHCPv6 is required for the connection to successfully activate, it will never succeed, and the interface never added to the required firewall zone.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Make a bootable media out of the custom F17 Alpha ISO at http://adamwill.fedorapeople.org/firewalld/firewalld-20120319-x86_64.iso
2. Boot it on a IPv6-only network using DHCPv6
The connection fails to activate.
The connection should activate.
There are two ways to solve this for F17 that I can see:
1) Make NM call fw_add_to_zone() at an earlier stage of device activation than the current nm_device_activate_schedule_ip6_config_result() - latest when the DHCPv6 client is started. This would make firewalld punch then necessary hole for DHCPv6 responses to make it back to the DHCPv6 client, allowing the connection to succeed.
2) Firewalld can adjust its default rule set so that DHCPv6 is always permitted regardless of zone configuration, as is the case for ICMPv6 traffic. Currently, the DHCPv6 client service is added to the default ruleset in a per-zone fashion only, so it is not allowed to interfaces not yet attached to any zone.
Created attachment 571622 [details]
syslog from when reproducing the problem
This syslog shows the problem happening repeatedly immediately after booting up firewalld-20120319-x86_64.iso. There are some comments in there I added using "logger -t" of what I did and when. Note that the final connection succeeded (and the interface was added to the public zone), because I manually punched a hole for DHCPv6 client traffic in the ip6tables ruleset.
This is using wired ethernet, however the exact same thing happens on WiFi as well.
I added some people to the CC list, too. This is because even though I filed this bug on the NetworkManager package, it can just as well be fully solved through modifying firewalld only. I believe Dan, Thomas, and Jiri should reach an agreement on who should implement the fix and where - and if it is in firewalld, the bug should be reassigned accordingly.
related ?: https://bugzilla.redhat.com/show_bug.cgi?id=798697
No, those two bugs are unrelated and confirmed fixed in the latest NM proposed update (if they weren't the connection would still not have succeeded even after manually punching the ip6tables hole for dhcpv6-client).
However they did prevent me from noticing this problem until now, unfortunately.
+1 blocker, I'm +1 on anything Tore says stops IPv6 working out of the box.
Fedora Bugzappers volunteer triage team
I've remembered that something similar (NM - dhcp - firewalld) was discussed on networkmanager-list AT gnome.org
On 08/01/2011 10:24 AM, Ludwig Nussel wrote:
> Dan Williams wrote:
>> One other note; if we want to block a bit on the firewall setting things
>> up, we want to slot this in during "stage3" (ip config start) before
>> "stage4" (ip config get) gets called, because only them do we know the
>> actual interface name to send to the firewall. For things like PPP,
>> PPPoE, Bluetooth DUN, etc, we don't know the actual IP interface name
>> until halfway through the connection setup process. But at that point
>> it should be safe to block for a short time for the firewall to do its
>> One other thought though, how do we handle DHCP with the firewall? NM
>> tries to do DHCP (which might need holes punched and stuff) during
>> "stage3", which in my proposal above is before the firewall would be
>> told the interface name. Is that a problem?
> DHCP clients bypass iptables for address configuration so the core
> DHCP feature should be fine. If the DHCP client or some hook script
> performs e.g. DNS lookups working connection tracking might be needed
> though. As long as the firewall always has a fallback rule that
> allows such kind of traffic for unassigned interfaces it's fine though.
But we obviously forgot about dhcpv6.
that's 3 +1s, accepting as blocker per criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" (as a proxy for 'network must work') in the IPv6 network case.
Fedora Bugzappers volunteer triage team
NetworkManager-0.9.3.997-1.git20120321.fc17 has been submitted as an update for Fedora 17.
NetworkManager-0.9.3.997-1.git20120321.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.