Bug 892801

*** Bug 904336 has been marked as a duplicate of this bug. ***

All I know is that UPnP/SSDP is something "Windows-related" so take my questions easy ;-)

Are you sure it's *source* port 1900 ?
I've read about UPnP and yes, all [1] the sources talk about 1900/udp & 2869/tcp but I can't see anything about source port. And the only iptables snippet [2] I found uses --dport 1900.

(just out of curiosity) What's your use case ?

[1]
http://en.wikipedia.org/wiki/Universal_Plug_and_Play#Protocol
http://support.microsoft.com/kb/886257#4
http://www.upnp-hacks.org/upnp.html

[2]
http://lists.fedoraproject.org/pipermail/users/2011-May/396236.html
http://www.gentoo-wiki.info/HOWTO_Setup_UPnP_with_IPTables

upnp can be used for discovery of multimedia and other networked devices. It also can instruct a network gateway to open ports for particular machine behind NAT (e.g. home network). This avoids the need to statically map network ports for applications.

The upnp service is running on port 1900 multicast (on the machine advertising services). The tcp port I guess is windows specific. Being multicast there is no conntrack. So matching the server replies to the app trying to open port or discover devices is not currently possible using stateful firewall.

That leaves us with a rule like:
iptables -I INPUT -s <your network> -p udp --sport 1900 -j ACCEPT

This is assuming outgoing multicast traffic is already allowed (what is the default).

This is what I have found without reading the upnp standard document. I wont be surprised if the facts above are not entirely true.

Instead of opening the firewall to all the local network I open it for data from a UPnP server (a NAS with IP 192.168.0.4). In this case, my computer reads data from the NAS thanks to the following rule:

firewall-cmd --direct --add-rule ipv4 filter IN_ZONE_home_allow 0 -p all --source 192.168.0.4 -j ACCEPT


I use the zone 'home' with IPv4.

But this solution has two problems:
1/ I need to use the switch '--direct' because Firewalld seems to be unable to allow all traffic from a given machine (or I didn't find how), hence this command relies very much on iptables instead of the abstraction from firewall-cmd,
2/ Because of '--direct', the result isn't persistent.

[bug 626188] talks about rygel and its specific to how to handle server side. The workaround for rygel - to set a fixed port via the rygel.conf is an acceptable and easy solution.

As a result of the issue highlighted in this bug (stating the obvious), is that UPnP clients like totem and vlc cannot identify, browse or play from UPnP servers.

I can reproduce this quite easily on F19. Totem discovers media shares quite easily when the firewall is turned off, or when one of the above rules are manually applied.

Having firewalld providing an option to enable UPnP clients like totem or vlc to use shares will be very helpful.

I have both upnp servers and clients

upnp protocol is pretty stupid and not firewall-friendly at all
From memory (so might be wrong): in discovery process, client sends a packet to 239.255.255.250 from a random port (let's say [12345]). Each server that listens on this broadcast IP (i.e. is upnp-enabled) sends a reply directly to the client's port [12345]. Since the reply doesn't come from 239.255.255.250 and doesn't come into a predetermined port, firewall (iptables, anyway) doesn't know how to process it, so it throws away the packet.
On server there's not much of a problem since the service can be bound to listen/reply on a specific port, as mentioned in comment 5

The only proper way I see of handling it on the client is to make an ftp-like handler -- scan all packets sent to 239.255.255.250/1900 (at least port 1900 is standard..) -- and temporarily open the source port to replies from any hosts on the network

How hard is it to implement this?

P.S. looks like firewalld is just an interface to netfilter.. so it would still need to be implemented as part of netfilter.. is that correct?

Yes, a netfilter based solution is needed.

Still valid in F20

I've started on a userspace helper for UPnP (SSDP), any help testing and tweaking it to get it merged would be appreciated. It works for me in it's current state, but may need more work :).

A full solution would require that firewalld be able to use conntrackd userspace helpers, not just the kernel helpers.

marc.info/?l=netfilter-devel&m=139429473308767&w=2

Thanks, so much!

This target needs to updated to F20. Since the changes have been accepted to upstream conntrack-tools, one must simply wait for them to make a new release. Then backport that to F20... Overall, will probably take some time.

As for firewalld, the problem is that there is no dynamic configuration for conntrackd: step [3] of [http://conntrack-tools.netfilter.org/manual.html#helpers]. Fedora's firewall would have to [1] register a userspace conntrack helper (simple, pre-enable action like module loading) [2] add a netfilter rule (already possible) [3] update conntrackd configuration (not possible afaik).

I'm not sure of the exact process of [helper -> iptables/CT -> iptables/NFQUEUE -> conntrackd]. Some of the steps seem redundant, but I assume te process is like so:
1] enable/disable helpers dynamically (nfct helper add)
2] configure netfilter to send matching packets to CT target
3] CT target is magic kernel module (libnetfilter_queue) that dispatches packets to proper NFQUEUE per /etc/conntrackd/conntrackd.conf
4] conntrackd (userspace) consumes packets and creates expectations (dynamically modifies incoming netfilter rules based on outgoing traffic)
5] expectations somehow unregister themselves after having been met.

If this is the case, fedora should provide conntrack-tools with all userspace helpers pre-configured in /etc/conntrackd/conntrackd.conf. Then firewalld simply adds/removes userspace helpers (nfct helper add/remove) under the assumption they are properly configured.

However I'm sure this proposal is bound to upset some people.

Needs input.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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 this bug is closed as described in the policy above.

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.

I think it has not been fixed.

*** Bug 1215266 has been marked as a duplicate of this bug. ***

(In reply to Laurent Aguerreche from comment #4)
> Instead of opening the firewall to all the local network I open it for data
> from a UPnP server (a NAS with IP 192.168.0.4). In this case, my computer
> reads data from the NAS thanks to the following rule:
> 
> firewall-cmd --direct --add-rule ipv4 filter IN_ZONE_home_allow 0 -p all
> --source 192.168.0.4 -j ACCEPT
> 

You can use source addresses in rich rules:

firewall-cmd --add-rich-rule="rule family=ipv4 source address=192.168.0.4 accept"
You can also add rich rules to the permanent environment with the --permanent option.
Please remember that you need to add the rule with and without the --permanent option to have it active immediately and also in the future after a reboot for example.

> 
> I use the zone 'home' with IPv4.
> 
> But this solution has two problems:
> 1/ I need to use the switch '--direct' because Firewalld seems to be unable
> to allow all traffic from a given machine (or I didn't find how), hence this
> command relies very much on iptables instead of the abstraction from
> firewall-cmd,
> 2/ Because of '--direct', the result isn't persistent.
You can also add direct rules to the permanent environment with the --permanent option.

This is still suboptimal as you allow all traffic instead of particular traffic type.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora  'version'
of '21'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 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 this bug is closed as described in the policy above.

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.

If think still not fixed in Fedora 22

minidlna works perfectly for me using this:

firewall-cmd --permanent --zone=home --add-source=239.255.255.250
firewall-cmd --permanent --zone=home --add-source=192.168.1.0/24
firewall-cmd --permanent --zone=home --add-service=minidlna

/etc/firewalld/services/minidlna.xml 
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>minidlna server</short>
  <description>ReadyMedia is server software with the aim of being fully compliant with DLNA/UPnP clients. </description>
  <port protocol="tcp" port="8200"/>
  <port protocol="udp" port="1900"/>
</service>

This is definitely not fixed yet. On Fedora 23, running Kodi from RPMFusion and using that as a UPnP client for various home media devices (including an HDHomeRun cable box)

I've searched a bit and tried some of the suggestions in this bz, but as long as firewalld is enabled I simply cannot get the UPnP client to see any traffic and devices. As soon as I disable firewalld, everything just works.

In fact, the Kodi guides for installing on Fedora 23 explicitly say to disable firewalld because there's no way to get this working otherwise. This is a shame, since it means I'll need to basically have no firewall at all running which seems like a security risk.

http://kodi.wiki/view/HOW-TO:Install_Kodi_on_Fedora_23_using_RPMFusion_packages

/me goes to disable firewalld on his machines

I'm really frustrated, how many years are needed to have at least source port support in firewalld rich rules so that one can have a working UPnP client?

This will be available in some days now.

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

(In reply to Thomas Woerner from comment #23)
> This will be available in some days now.

Any news here?

The availability was for source port support, which is available since firewalld version 0.4.2.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 EOL if it remains open with a Fedora  'version'
of '25'.

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.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 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 this bug is closed as described in the policy above.

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.

I don't see this resolved in f26.

What I am using now is:

> # accept UPnP responses from router - use your router address
> firewall-cmd --add-rich-rule="rule family=ipv4 source address=192.168.0.1 source-port port=1900 protocol=udp accept"
> # allow incoming connections to your app - this is example rule
> firewall-cmd --add-rich-rule="rule family=ipv4 port port=12345 protocol=tcp accept"
> # check rules are fine
> firewall-cmd --list-all
> # save rules to permanent storage
> firewallctl runtime-to-permanent

HTH somebody.

In Fedora 28 you can do:

firewall-cmd --add-service=upnp-client  # add --permanent to persist after reboot


Please note that this is dangerous, as it allows anybody to reach your closed UDP ports by sending packets with source port 1900. It should only be allowed for source IPs in the local subnet, but firewalld does not offer that capability AFAIK.

(In reply to Dimitrios Apostolou from comment #30)
> In Fedora 28 you can do:
> 
> firewall-cmd --add-service=upnp-client  # add --permanent to persist after
> reboot
> 
> 
> Please note that this is dangerous, as it allows anybody to reach your
> closed UDP ports by sending packets with source port 1900. It should only be
> allowed for source IPs in the local subnet, but firewalld does not offer
> that capability AFAIK.

You can use a rich rule to limit the source IPs. e.g.

  "source address=1.2.3.4/24 service name=upnp-client accept"

Thanks! Is there a way to limit the source IP address to the LAN subnet of each interface, regardless of what that would be?

(In reply to Dimitrios Apostolou from comment #32)
> Thanks! Is there a way to limit the source IP address to the LAN subnet of
> each interface, regardless of what that would be?

No. I don't think so.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. 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
EOL if it remains open with a Fedora  'version' of '27'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 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 this bug is closed as described in the policy above.

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.

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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