Bug 783002 - Standard firewall blocks IPv6 UDP ports 546 and 5353
Standard firewall blocks IPv6 UDP ports 546 and 5353
Status: RESOLVED FIXED
: 885475 (view as bug list)
Classification: openSUSE
Product: openSUSE 12.3
Classification: openSUSE
Component: Network
RC 2
x86-64 SUSE Other
: P5 - None : Normal (vote)
: ---
Assigned To: Marcus Meissner
E-mail List
maint:released:sle11-sp2:51914 GOLD
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-01 13:13 UTC by Freek de Kruijf
Modified: 2014-07-21 08:08 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
firewall log in case access to port 546 is not allowed (4.79 KB, text/plain)
2012-10-03 09:32 UTC, Freek de Kruijf
Details
NetworkManager log in case access to port 546 is not allowed (38.59 KB, text/plain)
2012-10-03 09:35 UTC, Freek de Kruijf
Details
firewall log in case access to port 546 is allowed (5.87 KB, text/plain)
2012-10-03 09:37 UTC, Freek de Kruijf
Details
NetworkManager log in case access to port 546 is allowed (16.51 KB, text/plain)
2012-10-03 09:39 UTC, Freek de Kruijf
Details
firewall log in case access to port 546 is not allowed using wireless (13.74 KB, text/plain)
2012-10-03 12:01 UTC, Freek de Kruijf
Details
NetworkManager log in case access to port 546 is not allowed using wireless (33.75 KB, text/plain)
2012-10-03 12:05 UTC, Freek de Kruijf
Details
firewall log in case access to port 546 is allowed using wireless (5.29 KB, text/plain)
2012-10-03 12:08 UTC, Freek de Kruijf
Details
NetworkManager log in case access to port 546 is allowed using wireless (20.43 KB, text/plain)
2012-10-03 12:09 UTC, Freek de Kruijf
Details
libpcap formatted file with ICMPv6 and DHCPv6 packets (7.49 KB, application/octet-stream)
2012-10-05 23:32 UTC, Freek de Kruijf
Details
SuSEfirewall2.dhcp6-server template (507 bytes, text/plain)
2013-03-12 15:13 UTC, Marius Tomaschewski
Details
patch file for SuSEfirewall2.sysconfig in package SuSEfirewall2-3.6.305 (667 bytes, patch)
2014-03-03 20:54 UTC, Freek de Kruijf
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Freek de Kruijf 2012-10-01 13:13:09 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1

It appears that the IPv4 UDP ports 46 (DHCP) and 5353 (mDNS) are opened by default in SuSEfirewall2, however the equivalent ports in IPv6 UDP port 546 and UDP 5353 are blocked (dropped). This causes problems in establishing a stable connection using NetworkManager. See bug#778434.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Marcus Meissner 2012-10-02 06:57:38 UTC
hmm
Comment 2 Marcus Meissner 2012-10-02 07:05:40 UTC
no ports are opened by default usually, but if applications send stuff out over ports, they are associated open for a bit.

need to be looked at
Comment 3 Ludwig Nussel 2012-10-02 08:03:24 UTC
The difference between ipv4 dhcp and ipv6 dhcp could be that the former might use raw sockets to bypass the packet filter. mDNS should be unrelated to the problems you describe.
Comment 4 Freek de Kruijf 2012-10-02 08:20:44 UTC
I will repeat the tests I did with the current 0.9.4 NetworkManager, enabling and disabling the filters for these ports in the firewall. Both in an environment with a wired and a wireless interface. These two environments were more stable with the filters, however not stable enough. In the wireless environment after about 15 minutes the connection is broken and need a restart. In the wired environment the connection in broken for a few seconds, but establishes a new connection automatically.

In case you have suggestions, please mention these.
Comment 5 Freek de Kruijf 2012-10-03 09:30:50 UTC
In the wired environment I removed the filter for port 5353 and nothing changed in the stability of the connection. However enabling the filter for 546 made the connection stay for about 20 minutes after which it reconnects automatically. Without that filter the connection stays for about 45 seconds and reconnects automatically. I attach the files /var/log/firewall and /var/log/NetworkManager, the 1 version in case there is no filter allowing packets to port 546 and the 2 version in which that filter allows access for those packets. 

The disconnect after about 20 minutes seems to be a bug in NetworkManager.

Next test will be in the wireless environment.
Comment 6 Freek de Kruijf 2012-10-03 09:32:08 UTC
Created attachment 508098 [details]
firewall log in case access to port 546 is not allowed
Comment 7 Freek de Kruijf 2012-10-03 09:35:20 UTC
Created attachment 508100 [details]
NetworkManager log in case access to port 546 is not allowed

The timeouts of DHCP6 after 45 seconds causes a disconnect. Apparently this is because the expected packet(s) do(es) not arrive within that time.
Comment 8 Freek de Kruijf 2012-10-03 09:37:14 UTC
Created attachment 508101 [details]
firewall log in case access to port 546 is allowed
Comment 9 Freek de Kruijf 2012-10-03 09:39:04 UTC
Created attachment 508102 [details]
NetworkManager log in case access to port 546 is allowed

Here you can see that the connection stays for about 20 minutes
Comment 10 Freek de Kruijf 2012-10-03 12:01:43 UTC
Created attachment 508115 [details]
firewall log in case access to port 546 is not allowed using wireless

Now using NetworkManager 0.9.4 in which case the connection is automatically restored, where 0.9.0.2 did not do that
Comment 11 Freek de Kruijf 2012-10-03 12:05:34 UTC
Created attachment 508118 [details]
NetworkManager log in case access to port 546 is not allowed using wireless

After the 45 seconds timeout of DHCP6 the connection needs to be restarted, which is almost once per minute. In contrary to the previous version of NetworkManager the reconnect is automatically.
Comment 12 Freek de Kruijf 2012-10-03 12:08:29 UTC
Created attachment 508120 [details]
firewall log in case access to port 546 is allowed using wireless

Also note that using wireless a filter in SuSEfirewall2 allows packets to UDP port 5353. Removing this filter does not change anything is respect to the stability of the connection.
Comment 13 Freek de Kruijf 2012-10-03 12:09:15 UTC
Created attachment 508121 [details]
NetworkManager log in case access to port 546 is allowed using wireless
Comment 14 Freek de Kruijf 2012-10-04 21:50:56 UTC
I did build the 0.9.7 version of NetworkManager and tested it in both the wireless and wired environment. The file /var/log/NetworkManager only has log lines from the start of NetworkManager. After that there are no more log lines in contrary to version 0.9.4. However this is only true when /etc/sysconfig/SuSEfirewall2 contains a filter to accept packages to IPv6 UDP port 564 from fe80::/64. Otherwise there is a timeout after 45 seconds for DHCP6, which resets the interface. So in that case the connection is unstable.
Comment 15 Freek de Kruijf 2012-10-05 23:25:31 UTC
The problem seems to be that the kernel (ip6tables?) does not notice the sending of the DHCPv6 solicitation request from the client, which is an outgoing packet, and after that does not allows an answer, advertisement, on that packet to be accepted. After which the client sends a request and should be allowed to receive the reply.
Comment 16 Freek de Kruijf 2012-10-05 23:31:24 UTC
(In reply to comment #2)
> no ports are opened by default usually, but if applications send stuff out over
> ports, they are associated open for a bit.
> 
> need to be looked at

This assumption seems to be not true, the port is not opened for a bit.

I will attach a wireshark trace file in which at first the firewall blocks the answer from the DHCPv6 server. At the end of the trace the firewall allows these packets and the client sends a request which receives a reply from the server.
Comment 17 Freek de Kruijf 2012-10-05 23:32:50 UTC
Created attachment 508434 [details]
libpcap formatted file with ICMPv6 and DHCPv6 packets
Comment 18 Marcus Meissner 2012-10-11 14:41:55 UTC
looked through susefirewall a bit, the conntrack related rules are setup same as ipv4. need to dig deeper.
Comment 19 Freek de Kruijf 2012-10-11 22:02:04 UTC
The main difference for DHCP is that IPv4 starts with a broadcast and IPv6 with a multicast. In case you need some package catching, I can make these with wireshark. In fact I do have three cases already, each one corresponding with the three choices my router provides with DHCP. Only providing DNS server, DNS + prefix and DNS + prefix + IPv6 address. In the last case the router only provides the address derived from the MAC address. So the router needs some more improvements.
Comment 20 Marcus Meissner 2012-10-16 07:07:49 UTC
Thanks for the detailed evaluation!

A correct solution would be some kind of conntrack module that briefly opens this port if an outgoing packet is received.

http://www.spinics.net/lists/netfilter-devel/msg20826.html

has a draft patch which is however not yet in the mainline kernel.


Not exactly sure what the merge status is here ... perhaps Jan knows?


As a temporary workaround we might have to allow the ipv6/546 port
Comment 21 Jan Engelhardt 2012-10-17 14:03:50 UTC
The DHCPv6 tracker has not been merged so far.

What you can do is increase the timeout value:

 ip6tables -t mangle -A PREROUTING -p udp --dport 546 -j CT --timeout dhcp6
 nfct timeout add dhcp6 inet6 udp unreplied 45 replied 60

to set the default timeout values for the unreplied and replied state to 45 and 60 s, respectively. (The system default is 30 s, and nfct(8) allows more fine-grained control over that.)
Comment 22 Freek de Kruijf 2012-10-17 14:37:34 UTC
In case the only change is to raise the timeout value I have my doubts that this helps. When I look at the timing of a complete DHCPv6 exchange, I see, in sequence, 2 solicit, 1 advertise, 2 request and 1 reply packet. The time between the first packet from the client and last packet from the server is 1.025 seconds. This is when I set the firewall to allow IPv6 UDP port 546 coming into the system with the client. Otherwise the advertise packet is dropped by the firewall.
Comment 23 Jan Engelhardt 2012-10-17 15:28:07 UTC
I don't spot the problem - what exactly is the issue? Leaving NM out of the picture would simplify it probably, as well.
Comment 24 Marcus Meissner 2012-10-17 15:38:34 UTC
the problem is that the outgoing DHCPv6 request goes to a multicast address,
but return packet comes from a specific host.

so a related rule is not possible, it needs some special conntrack registering hook.

as in ... outbound packet ... open port 546 for some seconds
Comment 25 Freek de Kruijf 2012-10-17 16:21:07 UTC
To be precise the above mentioned solicit and request packages from the client go to a multicast address ff02::1:2, MAC address 33:33:00:01:00:02. The advertise and reply packets from the server have the MAC addresses of the sender, a server, and the receiver, the client.

NM is not important for the result, most likely there is no outside network connection at least not with the requires IPv6 address.
Comment 26 Freek de Kruijf 2012-10-17 21:48:21 UTC
When you look at the issue with port 546, you might as well look at port 5353. In this case all packages to udp port 5353 have destination addresses: multicast IPv6 address ff02::fb, MAC address 33:33:00:00:00:fb, there is no unicast involved.
Comment 27 Freek de Kruijf 2012-12-01 11:42:40 UTC
Any progress on this issue?
Comment 28 Jan Engelhardt 2013-01-12 23:34:02 UTC
IIRC, what the conntrack maintainer suggests is that the userspace helper infrastructure that has recently been added to the kernel can be used to write helpers for e.g. DHCP.
For further inquiries, contact Pablo Ayuso or netfilter-devel@vger.kernel.org.
Comment 29 Jan Engelhardt 2013-01-12 23:35:34 UTC
Quoting, """We now have the user-space infrastructure in mainline.

Implementing this in user-space should be fairly easy. It will just
require a small port of that patch [p1] and running conntrackd."""

[p1] http://www.spinics.net/lists/netfilter-devel/msg20826.html
Comment 30 Freek de Kruijf 2013-01-14 21:05:56 UTC
I don't understand these solutions. My reasoning is that these DHCP packages and port 5353 packages are all coming from a link local address or are even multicast packages, so originate from a system on the link. I may be wrong, but why is it not possible to allow all these ipv6 packages by default in ip6tables?
Comment 31 Marcus Meissner 2013-01-24 16:05:20 UTC
I am trying to contact Pablo to get this forward.
Comment 32 Marius Tomaschewski 2013-03-12 15:13:27 UTC
Created attachment 529333 [details]
SuSEfirewall2.dhcp6-server template

BTW:
The dhcp server does not ship any dhcpv6 server template yet.

I'm going to add it (opens the dhcpv6-server 547/udp port only)
to the package with reference to this bug.

Unfortunately, the templates do not allow to specify IPv6-only
or IPv4-only ports, so when it is used it is open for both...
Comment 33 Marius Tomaschewski 2013-03-12 15:14:36 UTC
Back to SuSEfirewall2 maintainer.
Comment 35 Bernhard Wiedemann 2013-03-12 16:00:08 UTC
This is an autogenerated message for OBS integration:
This bug (783002) was mentioned in
https://build.opensuse.org/request/show/158697 Factory / dhcp
Comment 37 Bernhard Wiedemann 2013-03-27 15:00:12 UTC
This is an autogenerated message for OBS integration:
This bug (783002) was mentioned in
https://build.opensuse.org/request/show/161431 Maintenance / 
https://build.opensuse.org/request/show/161433 Maintenance / 
https://build.opensuse.org/request/show/161435 Maintenance /
Comment 39 Bernhard Wiedemann 2013-03-27 16:00:08 UTC
This is an autogenerated message for OBS integration:
This bug (783002) was mentioned in
https://build.opensuse.org/request/show/161437 Maintenance / 
https://build.opensuse.org/request/show/161440 Maintenance /
Comment 40 Bernhard Wiedemann 2013-04-02 16:00:24 UTC
This is an autogenerated message for OBS integration:
This bug (783002) was mentioned in
https://build.opensuse.org/request/show/162229 Evergreen:11.2 / dhcp
Comment 41 Swamp Workflow Management 2013-04-04 15:04:46 UTC
openSUSE-SU-2013:0619-1: An update that solves one vulnerability and has one errata is now available.

Category: security (moderate)
Bug References: 783002,811934
CVE References: CVE-2013-2266
Sources used:
openSUSE 12.2 (src):    dhcp-4.2.4.P2-0.1.12.1
openSUSE 12.1 (src):    dhcp-4.2.4.P2-0.6.21.1
Comment 42 Swamp Workflow Management 2013-04-04 15:05:18 UTC
openSUSE-SU-2013:0620-1: An update that solves one vulnerability and has one errata is now available.

Category: security (moderate)
Bug References: 783002,811934
CVE References: CVE-2013-2266
Sources used:
openSUSE 12.3 (src):    dhcp-4.2.5.P1-0.2.4.1
Comment 43 Swamp Workflow Management 2013-04-04 16:04:58 UTC
openSUSE-SU-2013:0625-1: An update that solves one vulnerability and has 6 fixes is now available.

Category: security (moderate)
Bug References: 783002,784640,788787,791280,791289,794578,811934
CVE References: CVE-2013-2266
Sources used:
openSUSE 11.4 (src):    dhcp-4.2.4.P2-0.34.1
Comment 44 Bernhard Wiedemann 2013-04-05 14:00:21 UTC
This is an autogenerated message for OBS integration:
This bug (783002) was mentioned in
https://build.opensuse.org/request/show/162839 Evergreen:11.2 / dhcp
Comment 45 Sebastian Krahmer 2013-04-17 12:07:54 UTC
released
Comment 46 Marcus Meissner 2013-04-17 12:42:20 UTC
only a part of it ...

the netfilter DHCPv6 connection tracking module we wanted is not yet done :(
Comment 47 Swamp Workflow Management 2013-04-17 15:04:27 UTC
Update released for: dhcp, dhcp-client, dhcp-debuginfo, dhcp-debugsource, dhcp-devel, dhcp-relay, dhcp-server
Products:
SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP2 (i386, x86_64)
SLE-SDK 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP2 (i386, x86_64)
Comment 48 Freek de Kruijf 2013-07-31 20:40:15 UTC
I did a native installation of openSUSE 13.1 M3 using the Ruby YaST iso and choose during installation the use of NetworkManager. Immediately after the generation, when KDE is active, and IPv6 is not disabled during the installation, I found that IPv6 is not configured in NM. I needed to use the applet to configure IPv6. After that IPv6 was not activated. I needed to reboot the system to get IPv6 active, however it suffered from the same problem as is presented in this bug report. I needed to open port UDP,546 in the firewall to get a stable connection. I used:
FW_SERVICES_ACCEPT_EXT="fe80::/64,udp,546" to open that port.
Comment 49 Freek de Kruijf 2014-03-03 20:54:41 UTC
Created attachment 580786 [details]
patch file for SuSEfirewall2.sysconfig in package SuSEfirewall2-3.6.305
Comment 50 Marcus Meissner 2014-03-04 16:41:47 UTC
As still no upstream DHCPv6 connection tracking has appeared I would probably go with something simialr to this niow.

Ludwig, do you have any better ideas?
Comment 51 Marius Tomaschewski 2014-05-23 07:53:20 UTC
See https://github.com/openSUSE/susefirewall2/pull/1 as an another attempt.
A "fe80::/64" is sufficient (comment 49) in most cases, but when the server
requests to use unicasts, the client "SHOULD" follow and then you've also
messages using global addresses.
Comment 52 Marius Tomaschewski 2014-05-23 08:02:26 UTC
BTW: There are also DHCPv6 servers, which send responses from dynamic ports
and not from 547 [I found some info, that zyxel dhcpv6 server is doing it].
Comment 53 Marius Tomaschewski 2014-05-23 08:09:39 UTC
See also https://github.com/openSUSE/susefirewall2/pull/2 which enables
dhcpv6-client configuration by default.
Comment 55 Marcus Meissner 2014-05-27 15:42:00 UTC
After some discussion I think we arrived currently at the conclusion to default allow dhcpv6 incoming.

We can harden / restrict this, pending on new connection tracking modules or perhaps add config variables.
Comment 56 Bernhard Wiedemann 2014-05-27 16:00:14 UTC
This is an autogenerated message for OBS integration:
This bug (783002) was mentioned in
https://build.opensuse.org/request/show/235571 Factory / SuSEfirewall2
Comment 57 Marcus Meissner 2014-05-28 12:58:07 UTC
also queuing this as a maintenance update for 12.3 and 13.1
Comment 58 Swamp Workflow Management 2014-06-12 09:05:00 UTC
openSUSE-RU-2014:0779-1: An update that has one recommended fix can now be installed.

Category: recommended (low)
Bug References: 783002
CVE References: 
Sources used:
openSUSE 13.1 (src):    SuSEfirewall2-3.6.305-2.4.1
openSUSE 12.3 (src):    SuSEfirewall2-3.6.302-1.4.1
Comment 59 Alexander Bergmann 2014-07-02 13:54:29 UTC
*** Bug 885475 has been marked as a duplicate of this bug. ***
Comment 60 Swamp Workflow Management 2014-07-21 08:08:46 UTC
openSUSE-RU-2014:0927-1: An update that has two recommended fixes can now be installed.

Category: recommended (low)
Bug References: 783002,887850
CVE References: 
Sources used:
openSUSE 12.3 (src):    SuSEfirewall2-3.6.302-1.8.1