Bug 858327 - ip6tables block dhcpd6 from working
ip6tables block dhcpd6 from working
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
17
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-18 12:43 EDT by Gene Czarcinski
Modified: 2013-07-31 21:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 21:31:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Gene Czarcinski 2012-09-18 12:43:44 EDT
Description of problem:
By default, ip6tables is blocking dhcpd6 from receiving any packets.

Client requests come from port 546 and are sent to port 547 with address ff02::1:2.

Until ip6tables is stopped, nothing is happening.  With it stopped, dhcpd6 is responding.

Yes, I know that firewalld is comming and will fix everything but this should not be happening.

Version-Release number of selected component (if applicable):
Fedora 17, iptables-1.4.14-2.fc17.x86_64, dhcp-4.2.4-9.P1.fc17.x86_64

How reproducible:
yes

Steps to Reproduce:
Install Fedora 17, install dhcp, configure dhcpd6 and start it.
Start wireshare to monitor the interface, have a client startup an IPv6 network with dhcp specified.

  
Actual results:
blocked

Expected results:
works

Additional info:

Here are the client request and the server's response (at least the basic descriptions from wireshark) --

Internet Protocol Version 6, Src: fe80::5054:ff:fe96:3670 (fe80::5054:ff:fe96:3670), Dst: ff02::1:2 (ff02::1:2)
User Datagram Protocol, Src Port: dhcpv6-client (546), Dst Port: dhcpv6-server (547)

Internet Protocol Version 6, Src: fe80::5054:ff:fe16:5ae0 (fe80::5054:ff:fe16:5ae0), Dst: fe80::5054:ff:fe96:3670 (fe80::5054:ff:fe96:3670)
User Datagram Protocol, Src Port: dhcpv6-server (547), Dst Port: dhcpv6-client (546)


I was going to report this against iptables but decided it made more sense that the dhcp package should have the responsibility.  Not many systems will be running dhcpd6 so opening up a system should be something that happens when dhcpd6.service is started.  In addition, with the future use of firewalld something will need to work there too.

This took more than a couple of hours to figure out since this was the first time I had configured dhcpd6 and thought I had screwed up the configuration.  Fortuinately, someone else had the problem and posted a message about it.  But, this is a bug and he should have reported it.
Comment 1 Jiri Popelka 2012-09-19 04:35:02 EDT
(In reply to comment #0)
> I was going to report this against iptables but decided it made more sense
> that the dhcp package should have the responsibility.  Not many systems will
> be running dhcpd6 so opening up a system should be something that happens
> when dhcpd6.service is started.

Yes, I agree that the responsibility for this is not on iptables.
On the other side I don't know how to easily and reliably fix this in dhcp.
dhcpd6 service could run
'ip6tables -A INPUT -p udp -m state --state NEW -m udp --dport 547 -j ACCEPT'.
during start, but the problem occurs when iptables service is restarted, saved
rules are read and our open port 547 is closed again.

>In addition, with the future use of
> firewalld something will need to work there too.

Yes, it's possible that this will be much easier with firewalld.
That's one of the aims of it.
 
> This took more than a couple of hours to figure out since this was the first
> time I had configured dhcpd6 and thought I had screwed up the configuration.

I know exactly what you are talking about. I remember myself tearing my hair out
for several days trying to figure out what's wrong with my first dhcpd6 configuration.

> But, this is a bug and he should have reported it.

I don't know any service that itself opens a port(s) in firewall so I wouldn't classify
this as a bug. For me it's a feature request and I'm leaving this open as in the
future we can see a solution solving this problem not just for dhcpd6 service.
Comment 2 Gene Czarcinski 2012-09-19 10:24:30 EDT
IIRC, a whole bunch of years ago when iptables was first made standard part of the distribution, ntp (ntpd) would blast a whole for itself on port 123.

If dhcpd6 is started and stopped by systemctl, I would think that it would be possible a to add a rule when started and remove that rule when stopped.

And then there is the question of how serious it is security-wise to just open port 547 for input (546 for input is already allowed).  Maybe you caould ask some of the security gurus on Fedora and/or Red Hat.  I know some guys who are paid big bucks on computer security ... let me run this question passed them too.
Comment 3 Fedora End Of Life 2013-07-03 19:07:55 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 4 Fedora End Of Life 2013-07-31 21:31:15 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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