Bug 805405

Summary: NM adds device to firewall zone after successful activation, causing a DHCPv6 catch-22
Product: [Fedora] Fedora Reporter: Tore Anderson <tore>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 17CC: awilliam, bruno, dcbw, jpopelka, jsmith.fedora, rbergero, robatino, satellitgo, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: NetworkManager-0.9.3.997-1.git20120321.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-23 17:43:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 752649    
Attachments:
Description Flags
syslog from when reproducing the problem none

Description Tore Anderson 2012-03-21 07:54:25 UTC 
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):

NetworkManager-0.9.3.997-0.7.fc17
firewalld-0.2.4-1.fc17

How reproducible:

100%

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
3. 
  
Actual results:

The connection fails to activate.

Expected results:

The connection should activate.

Additional info:

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.
Comment 1 Tore Anderson 2012-03-21 08:02:54 UTC 
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.
Comment 2 satellitgo 2012-03-21 12:32:08 UTC 
related ?: https://bugzilla.redhat.com/show_bug.cgi?id=798697
Comment 3 satellitgo 2012-03-21 12:35:28 UTC 
https://bugzilla.redhat.com/show_bug.cgi?id=538499
Comment 4 Tore Anderson 2012-03-21 14:27:38 UTC 
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.

Tore
Comment 5 Adam Williamson 2012-03-21 16:07:14 UTC 
+1 blocker, I'm +1 on anything Tore says stops IPv6 working out of the box.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Jiri Popelka 2012-03-21 17:48:50 UTC 
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
>> work.
>>
>> 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.
Comment 7 Kevin Fenzi 2012-03-21 22:59:05 UTC 
+1 blocker.
Comment 8 Jared Smith 2012-03-21 23:02:00 UTC 
+1 blocker
Comment 9 Robyn Bergeron 2012-03-21 23:17:23 UTC 
+1 blocker
Comment 10 Adam Williamson 2012-03-21 23:17:43 UTC 
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
https://fedoraproject.org/wiki/BugZappers
Comment 11 Fedora Update System 2012-03-21 23:51:42 UTC 
NetworkManager-0.9.3.997-1.git20120321.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.3.997-1.git20120321.fc17
Comment 12 Bruno Wolff III 2012-03-22 02:17:56 UTC 
+1 blocker
Comment 13 Fedora Update System 2012-03-23 17:43:20 UTC 
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.