Bug 626188

Summary: Firewall doesn't know about Rygel
Product: [Fedora] Fedora Reporter: Tobias Mueller <fedora-bugs>
Component: system-config-firewallAssignee: Thomas Woerner <twoerner>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 24CC: agrover, akostadi, aleksander, ashes-iontach, awilliam, bnocera, bruce, csaavedra, debarshir, djasa, ignatenko, john.haxby, jpopelka, juliusvonkohout, jussi.kukkonen, lgalosha, mail, marcandre.lureau, maurizio.antillon, mcatanzaro, michael.wiktowy, redhat-bugzilla, samuel-rhbugs, sanjay.ankur, s, stefan.home, turakas, twoerner, zali
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=892801
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-23 14:41:06 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Add option to permit 'UPnP' discovery protocol none

Description Tobias Mueller 2010-08-22 11:56:48 EDT
Description of problem:
Firewall blocks Rygel

Version-Release number of selected component (if applicable):


How reproducible:
Install rygel, try to use it, fail.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
No button in the firewall preferences to enable Rygel.

Expected results:
I expected to be able to check a button in the firewall configuration to enable Rygel. 

Additional info:
Comment 1 Peter Robinson 2010-08-22 12:31:37 EDT
The problem isn't with rygel but rather the firewall config tool
Comment 2 Zeeshan Ali 2011-05-07 15:29:20 EDT
This bug has been awaiting a long time and is pretty critical since rygel just can't work without the fix for this. I always get angry users who tell me that rygel doesn't work for them and its always because of default firewall rules not allowing UPnP ports. Can this be fixed anytime soon please?
Comment 3 Marc-Andre Lureau 2011-05-07 15:41:14 EDT
I second Zeeshan, it would be great to make it easier for users to share media through UPnP without having to deal with his firewall configuration.
Comment 4 Jens Georg 2011-05-08 06:18:54 EDT
Yes, please. This is really annoying.
Comment 5 Thomas Woerner 2011-05-09 04:22:14 EDT
Do you have information on ports and rules, that are needed for this?

The documentation of rygel does not cover firewall settings at all.

This is the only information I could find in a mailing list, but it also says that the 34567 port is dynamic and that this has not been tested at all:

239.255.255.250:1900/UDP
localhost:1900/UDP
localhost:34567/TCP
Comment 6 Zeeshan Ali 2011-05-09 09:16:57 EDT
(In reply to comment #5)
> Do you have information on ports and rules, that are needed for this?
> 
> The documentation of rygel does not cover firewall settings at all.

  Thats because user doesn't need to know that, in fact we don't even want him/her to know about existence of rygel. :)

> This is the only information I could find in a mailing list, but it also says
> that the 34567 port is dynamic and that this has not been tested at all:
> 
> 239.255.255.250:1900/UDP
> localhost:1900/UDP

  This is correct, except for the localhost part, you want to allow 1900 port on every address/iface. If you don't want this port to be open by default, I suggest creating a special config for "UPnP" (Its SSDP actually but nobody uses the protocol without UPnP) that opens these ports. AFAIK, Windows does that. Its still very annoying for users but its still better than asking users to disable their firewalls completely.

> localhost:34567/TCP

  This one is pretty much dynamic and is decided by libsoup (SoupServer) for us but afaik there is no issues with these (user) ports?
Comment 7 Bug Zapper 2011-06-01 06:49:52 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Claudio Saavedra 2011-11-07 16:27:25 EST
Still not working out of the box? With Zeeshan now working for Red Hat even? Bummer :)
Comment 10 Andy Grover 2011-11-14 14:51:52 EST
Maybe attaching a patch would help get this going.

git clone git://git.fedorahosted.org/git/system-config-firewall

edit src/fw_services.py, add whatever services you want

create a patch with "git diff > rygel.patch"

Apply it to your test machine, verify option shows up and rygel works when it is checked

you could attach the patch to the fedorahosted trac, but might as well just attach it here and Thomas will probably pull it in.
Comment 11 Zeeshan Ali 2011-11-14 15:55:12 EST
Created attachment 533617 [details]
Add option to permit 'UPnP' discovery protocol
Comment 12 Zeeshan Ali 2011-11-14 17:43:13 EST
Forgot to mention that I didn't get to test this patch.
Comment 13 Jens Georg 2011-12-27 06:15:59 EST
(In reply to comment #11)
> Created attachment 533617 [details]
> Add option to permit 'UPnP' discovery protocol

I'm not sure that's enough. It's sufficient for the announcement case (device on the network sends the alive beacons) but not for active searching:

Fedora host sends SSDP mcast package from some random port (say 12345) → 1900, as per standard the reply has to go to port 12345 _and_ should not originate from port 1900 but another random port on the sending machine.
Comment 14 Fedora End Of Life 2012-08-07 16:18:21 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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 to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Marc-Andre Lureau 2012-08-08 06:52:39 EDT
(moving to rawhide to keep it open..)
Comment 16 Fedora End Of Life 2013-04-03 16:18:40 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 17 Jens Georg 2013-05-10 11:27:52 EDT
The patch in comment 11 should be correct for UPnP servers if the assumption about user ports in comment 6 is true. There might be an issue with UPnP clients, though.
Comment 18 Adam Williamson 2013-05-13 15:49:00 EDT
We replaced iptables with firewalld by default several cycles back. It may not be a good idea to repurpose this bug as iptables and s-c-f still exist and haven't been officially obsoleted yet, but it would probably be a good idea to also file a bug against firewalld , if it doesn't already handle this (from a quick look at /usr/lib/firewalld/services/ , I don't see anything relating to Rygel or UPnP).

Given how firewalld works, Rygel could actually request a hole in the firewall interactively; that's one of the things firewalld is intended to enable. So the app could be enhanced here as  well.
Comment 19 Adam Williamson 2013-05-13 15:49:41 EDT
CCing Jiri, who is active in firewalld maintenance ATM (along with Thomas).
Comment 20 john.haxby@oracle.com 2013-05-14 04:22:59 EDT
It's been a while since I was able to test this, but I don't think opening port 1900 is sufficient.   I'm not in a position to be able to test this at the moment.

As I recall, though, the client (eg a TV or a network-streaming amplifier) connects to the uPnP server on a port supplied as part of the exchange that was happening on port 1900 and that port was blocked.  As I say, this was a little while ago, but what seems to be needed is a conntrack module (in the kernel) that knows enough about the uPnP protocol to be able to mark the new connection as "related".   This isn't an iptables or a firewalld issue.

Obviously this hypothesis needs testing.
Comment 21 Ankur Sinha (FranciscoD) 2013-05-14 04:53:43 EDT
Only opening the 1900 port isn't enough. There's another port that needs to be opened, like Jens mentioned. This port is a dynamic port that libsoup uses, and is a user port. Are user ports open by default in the firewall? I don't think so. 

I manually specify a port for rygel to use via the configuration file and then open this up from firewalld to get rygel to work completely.

I was wondering how firewalld would know what this other port was, if it were dynamic.
Comment 22 Zeeshan Ali 2013-05-14 09:20:49 EDT
(In reply to comment #21)
> Only opening the 1900 port isn't enough.
>
> There's another port that needs to
> be opened, like Jens mentioned. This port is a dynamic port that libsoup
> uses, and is a user port. Are user ports open by default in the firewall? I
> don't think so. 

They really should be, no?

> I manually specify a port for rygel to use via the configuration file and
> then open this up from firewalld to get rygel to work completely.

So you are saying that you have tested that after you open port 1900, you still can't get rygel to work w/o the above?

> I was wondering how firewalld would know what this other port was, if it
> were dynamic.

I guess it wouldn't but as pointed out in comment#18, rygel could also be modified to punch holes in the firewall. Although I wonder if its a good idea for rygel to do that w/o asking or informing the user/admin. Maybe rygel should choose a specific port by default in the configuration rather than using dynamic port?
Comment 23 Ankur Sinha (FranciscoD) 2013-05-15 00:36:35 EDT
(In reply to comment #22)
> (In reply to comment #21)
> > Only opening the 1900 port isn't enough.
> >
> > There's another port that needs to
> > be opened, like Jens mentioned. This port is a dynamic port that libsoup
> > uses, and is a user port. Are user ports open by default in the firewall? I
> > don't think so. 
> 
> They really should be, no?

No clue. We'll need the firewalld folks to clarify this one. 

> 
> > I manually specify a port for rygel to use via the configuration file and
> > then open this up from firewalld to get rygel to work completely.
> 
> So you are saying that you have tested that after you open port 1900, you
> still can't get rygel to work w/o the above?

Yep. As far as I can tell. I'll re-test this and confirm over the weekend though. I don't want to open any ports here when I'm on university wifi. 

> 
> > I was wondering how firewalld would know what this other port was, if it
> > were dynamic.
> 
> I guess it wouldn't but as pointed out in comment#18, rygel could also be
> modified to punch holes in the firewall. Although I wonder if its a good
> idea for rygel to do that w/o asking or informing the user/admin. Maybe
> rygel should choose a specific port by default in the configuration rather
> than using dynamic port?

Any changes to firewall configurations need admin privileges. s-c-printer for example asks for permission before it opens ports to detect network printers. Rygel could use a specific port. That should make it slightly easier, yes.

Warm regards,
Ankur
Comment 24 Thomas Woerner 2013-05-15 05:47:54 EDT
(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > Only opening the 1900 port isn't enough.
> > >
> > > There's another port that needs to
> > > be opened, like Jens mentioned. This port is a dynamic port that libsoup
> > > uses, and is a user port. Are user ports open by default in the firewall? I
> > > don't think so. 
> > 
> > They really should be, no?
> 
> No clue. We'll need the firewalld folks to clarify this one. 
> 
No, user ports are not open by default in the firewall.

> > 
> > > I manually specify a port for rygel to use via the configuration file and
> > > then open this up from firewalld to get rygel to work completely.
> > 
> > So you are saying that you have tested that after you open port 1900, you
> > still can't get rygel to work w/o the above?
> 
> Yep. As far as I can tell. I'll re-test this and confirm over the weekend
> though. I don't want to open any ports here when I'm on university wifi. 
> 
> > 
> > > I was wondering how firewalld would know what this other port was, if it
> > > were dynamic.
> > 
> > I guess it wouldn't but as pointed out in comment#18, rygel could also be
> > modified to punch holes in the firewall. Although I wonder if its a good
> > idea for rygel to do that w/o asking or informing the user/admin. Maybe
> > rygel should choose a specific port by default in the configuration rather
> > than using dynamic port?
> 
> Any changes to firewall configurations need admin privileges. s-c-printer
> for example asks for permission before it opens ports to detect network
> printers. Rygel could use a specific port. That should make it slightly
> easier, yes.
> 
Any firewall change needs admin privileges.

If Rygel could use a specific port instead of a dynamic port, then this could be easily added to a new Rygel service entry.

With a dynamic port on the other hand there needs to be some mechanism in Rygel that tells firewalld to open this port. But still admin privileges are needed for this.

I thought also about a database to store information about applications that are allowed to open additional ports, but this does not exist, yet. This needs application policy support in firewalld.

> Warm regards,
> Ankur

Thomas
Comment 25 john.haxby@oracle.com 2013-05-15 05:52:39 EDT
> If Rygel could use a specific port instead of a dynamic port, then this could
> be easily added to a new Rygel service entry.

That would certainly make things easier.

> With a dynamic port on the other hand there needs to be some mechanism in Rygel
> that tells firewalld to open this port. But still admin privileges are needed
> for this.

Don't forget that Rygel isn't the only uPnP server.   A solution that would help *all* uPnP servers would be a conntrack helper: there are already conntrack helpers for various other protocols, adding a uPnP helper would, well, help everyone.
Comment 26 Thomas Woerner 2013-05-15 06:59:52 EDT
(In reply to comment #25)
> > If Rygel could use a specific port instead of a dynamic port, then this could
> > be easily added to a new Rygel service entry.
> 
> That would certainly make things easier.
> 
> > With a dynamic port on the other hand there needs to be some mechanism in Rygel
> > that tells firewalld to open this port. But still admin privileges are needed
> > for this.
> 
> Don't forget that Rygel isn't the only uPnP server.   A solution that would
> help *all* uPnP servers would be a conntrack helper: there are already
> conntrack helpers for various other protocols, adding a uPnP helper would,
> well, help everyone.

Yes, that would be the best solution. But it would surely take some time to have an upnp helper in netfilter.
Comment 27 Jiri Popelka 2013-05-16 04:19:05 EDT
(In reply to comment #18)
> it would probably be a good idea to also file a bug against firewalld

bug #892801 (and its duplicate bug #904336)
Comment 28 Aleksandar Kostadinov 2013-05-16 07:55:48 EDT
Is uPnP working over NAT? I thought it is only a local network protocol. And if it is only local network, then isn't it easier to have a layer 7 iptables match module that recognizes uPnP and can allow that kind of traffic to particular local ports?
Comment 29 john.haxby@oracle.com 2013-05-16 08:33:39 EDT
It can't work over NAT: uPnP clients discover servers by broadcasting and there is no way you can do that with NAT.

Also, an iptables conntrack helper does not imply NAT, merely the tracking of related packets.
Comment 30 Aleksandar Kostadinov 2013-05-16 08:49:24 EDT
@John, I don't know how upnp exactly works but I can't see how a mere con tracking can help. Are all connections initiated locally so contrack can be used to allow that traffic? So in the first place I htink an iptables module would be needed to match upnp packets.
Wouldn't the plain UDP contrack do the job once connections are established?
Comment 31 john.haxby@oracle.com 2013-05-16 08:55:45 EDT
No, plain udp conntrack isn't sufficient.   The protocol includes URLs for various resources: album covers, audio streams, etc.   I'm going from shaky memory of a few months back when I was looking more closely at this, but the URLs all have IP addresses instead of hostnames and it was not immediately obvious that the port could be specified in some configuration.   A conntrack helper needs to identify those URLs so that incoming connections can be allowed on the local subnet.

I'm not sure that this is possible, but some investigation is called for.   My local solution was simply to allow access from the various (fixed) IP addresses of the clients I have.   It's just around the house so it's a reasonably constrained environment.  Unfortunately uPnP was not designed with any sort of firewall in mind.
Comment 32 john.haxby@oracle.com 2013-05-16 08:56:23 EDT
For what it's worth, coherence has a good and useful uPnP browser.
Comment 33 Aleksandar Kostadinov 2013-05-16 09:11:13 EDT
@John, do you mean that a multicast packet specifies URLs? In this case I can't see how contrack can help because sending out a multicast packet doesn't mean any client will ever connect back even less it tells which one client.

Instead I think the firewall needs to recognize the incoming packets are upnp and destined to correct local ports. I am thinking that perhaps without modification of iptables, if upnp server listen ports can be fixed, then packets to these ports can be send to userspace and perhaps that can be a daemon that allows packets based on announcements made by upnp server. Or perhaps that daemon can have an iptables chain to manage and based on upnp announcements from local upnp servers and clients, it can enable/disable different local machine ports. 
This way no modification to contrack, iptables and upnp server/client would be needed. WDYT?
Comment 34 john.haxby@oracle.com 2013-05-16 09:16:56 EDT
You seem to be suggesting that the server sends multicast packets.  That's not the case.   The service listens for broadcast/multicast packets on port 1900: that's a fixed port.   It sends a response out to the client that sent the broadcast packet.   From that initial response, the client can now make further requests to discover what the server is offering.

This is the point at which things usually fail: the new connections are completely new to iptables and so they are blocked.  A conntrack helper would be able to recognise the URLs in initial reply and open the corresponding port(s) for the client to continue its discovery.

If, and it's a big if, there are only two ports involved: 1900 and some fixed configurable port, then we don't need conntrack.   The problem seems to be that this is not the case.
Comment 35 Aleksandar Kostadinov 2013-05-16 09:20:52 EDT
@John, if server sends unicast UDP to client and client replies with unicast udp, then why is not regular UDP conntrack not working? I'm running a VPN over UDP over the whole internet from NAT-ed machines with no problems, so it can't be the lack UDP conntracking.
Comment 36 john.haxby@oracle.com 2013-05-16 09:35:25 EDT
Because the payload in the response contains the URL telling the client where to connect to next.  Conntrack has absolutely no knowledge of this so iptables does not know that the next packet coming from the client is related to the original request and it blocks it.

The original request to port 1900 (which must be open) is not a problem.   It's the subsequent requests to a completely unrelated port that cause the issue.

I'm currently playing a track from a uPnP server on my hi-fi.   There is a TCP connection to the server on port 8200 (this isn't, as it happens, Rygel).  There is no way for UDP conntrack to work out that this is related.  You need a conntrack helper that understands enough of the protocol payload to recognise ports that need to be opened from the payload (the FTP conntrack helper does something similar).

In this particular case it might be enough to open 1900/udp and 8200/tcp but I'm not sure if that is true in the general case or if there are other ports that are needed.
Comment 37 Zeeshan Ali 2013-05-16 11:03:47 EDT
(In reply to comment #34)
> You seem to be suggesting that the server sends multicast packets.  That's
> not the case.   The service listens for broadcast/multicast packets on port
> 1900: that's a fixed port.   It sends a response out to the client that sent
> the broadcast packet.   From that initial response, the client can now make
> further requests to discover what the server is offering.
> 
> This is the point at which things usually fail: the new connections are
> completely new to iptables and so they are blocked.  A conntrack helper
> would be able to recognise the URLs in initial reply and open the
> corresponding port(s) for the client to continue its discovery.
> 
> If, and it's a big if, there are only two ports involved: 1900 and some
> fixed configurable port,

Its not. That is the only other incoming port. Its the port rygel runs its HTTP server on and it uses this port for *all* HTTP, including media transfer etc.

> then we don't need conntrack.   The problem seems
> to be that this is not the case.

I think to solve this issue w/o getting into too much trouble, we can choose a specific port in rygel's default configuration.
Comment 38 Zeeshan Ali 2013-05-16 11:05:20 EDT
(In reply to comment #37)
> (In reply to comment #34)
> > You seem to be suggesting that the server sends multicast packets.  That's
> > not the case.   The service listens for broadcast/multicast packets on port
> > 1900: that's a fixed port.   It sends a response out to the client that sent
> > the broadcast packet.   From that initial response, the client can now make
> > further requests to discover what the server is offering.
> > 
> > This is the point at which things usually fail: the new connections are
> > completely new to iptables and so they are blocked.  A conntrack helper
> > would be able to recognise the URLs in initial reply and open the
> > corresponding port(s) for the client to continue its discovery.
> > 
> > If, and it's a big if, there are only two ports involved: 1900 and some
> > fixed configurable port,
> 
> Its not. That is the only other incoming port. Its the port rygel runs its
> HTTP server on and it uses this port for *all* HTTP, including media
> transfer etc.


* Its not -> Its not an 'if :)
* only other incoming port -> only other incoming port other than the port 1900
Comment 39 Zeeshan Ali 2013-06-25 16:45:44 EDT
(In reply to Zeeshan Ali from comment #37)
> (In reply to comment #34)
> > You seem to be suggesting that the server sends multicast packets.  That's
> > not the case.   The service listens for broadcast/multicast packets on port
> > 1900: that's a fixed port.   It sends a response out to the client that sent
> > the broadcast packet.   From that initial response, the client can now make
> > further requests to discover what the server is offering.
> > 
> > This is the point at which things usually fail: the new connections are
> > completely new to iptables and so they are blocked.  A conntrack helper
> > would be able to recognise the URLs in initial reply and open the
> > corresponding port(s) for the client to continue its discovery.
> > 
> > If, and it's a big if, there are only two ports involved: 1900 and some
> > fixed configurable port,
> 
> Its not. That is the only other incoming port. Its the port rygel runs its
> HTTP server on and it uses this port for *all* HTTP, including media
> transfer etc.
> 
> > then we don't need conntrack.   The problem seems
> > to be that this is not the case.
> 
> I think to solve this issue w/o getting into too much trouble, we can choose
> a specific port in rygel's default configuration.

Sorry, that is not going to be easy. Rygel service/process runs per-session (should actually be per-user instead but that is not currently possible) so that is why the incoming HTTP port is set to be dynamic. i-e each rygel instance runs on a separate port allocated dynamically.

Unless we can assign a port range to rygel, this is not going to work.
Comment 40 Michael Wiktowy 2013-07-25 00:13:11 EDT
I am enabling Rygel indirectly via the Media Sharing switch in the Gnome 3 settings. My expectation was that, by turning things on there and not starting Rygel manually at system start-up, the firewall rules would have been authorized and mangled appropriately for things to work out-of-the-box. I was a bit disappointed that with firewalld, manual intervention was required for things to work across the local network.

Right now, to get around having to use 'lsof -i' to figure out the ports Rygel is currently using and reconfigure the firewall after each reboot, I am following the instructions on:

http://ankursinha.in/blog/2013/05/12/setting-up-rygel-on-your-fedora-system/

to set a static port for Rygel.

Then I can manually open a permanent port in firewalld and not have to deal with it any more.

That is not out-of-the-box working though. I would assume that if "Media Sharing" requires firewall fiddling then so will the DAV-based "Personal File Sharing" and the VNC-based "Screen Sharing" but I investigated those options yet. Perhaps this firewalld fiddling should be handled at the GNOME 3 settings level and the ports to use can be passed to firewalld and the appropriate services on start-up. Then everything can "just work".
Comment 41 Miloslav Trmač 2013-09-30 11:09:27 EDT
(In reply to Thomas Woerner from comment #24)
> I thought also about a database to store information about applications that
> are allowed to open additional ports, but this does not exist, yet. This
> needs application policy support in firewalld.

Not only in firewalld; this requires a (currently completely non-existent) way to reliably identify and isolate applications.  It's being worked on, but it will take a _long_ time.
Comment 42 Jussi Kukkonen 2013-11-25 10:17:30 EST
I had a discussion of this with some people who understand networking better than I do, thought I'd post here for comments.

First wrapping up the situation:
* control messages go through standard SSDP port 1900 as UDP messages that are "http-ish" (basically just a few of headers)
* one of the headers includes the port to be used as the actual data channel (which is http over TCP). This port is variable.


Possible solutions:
1. rygel (or gupnp) talks to firewalld and asks it to open ports when it starts a service (and there's a mechanism for rygel to have permission to do that). This probably works but only for firewalld.

2. John Haxby suggested a conntrack helper. The idea here seems to be that the helper watches the traffic on port 1900, and when it sees outgoing messages with the right header, it marks the mentioned port as "related" for some amount of time. There may be additional complexities here -- as an example I'm not sure if this solution is meant to scale to the time lengths needed -- but it seems like a viable idea. It seems this would really need to be in the kernel (and not just user space using the conntrack api) because of the need to inspect the control messages for the port.

Looking at the similar ftp helper for conntrack, it looks like a fairly simple job -- messages being UDP helps a lot. I might have time to try this but maybe someone could first comment on whether solution #2 sounds acceptable (from Fedora and/or RH point of view)? After all, any app that is allowed to send things through 1900 can then "open ports" as they want.
Comment 43 Thomas Woerner 2013-12-06 09:04:00 EST
From a portability standpoint I would say solution 2. From a security stand point I would say solution 1.

If you are allowing uPNP, then the behaviour of solution 2 would be most likely expected.
Comment 44 Aleksandar Kostadinov 2013-12-11 06:22:56 EST
What about user-space conntrack helper [1][2]?

[1] https://lkml.org/lkml/2013/5/7/830
[2] http://post-office.corp.redhat.com/archives/tech-list/2013-December/msg00151.html
Comment 45 Jussi Kukkonen 2013-12-11 06:57:18 EST
(In reply to Aleksandar Kostadinov from comment #44)
> What about user-space conntrack helper [1][2]?
> 
> [1] https://lkml.org/lkml/2013/5/7/830
> [2]
> http://post-office.corp.redhat.com/archives/tech-list/2013-December/msg00151.
> html

I'm certainly not an expert on conntrack, but I believe that does not work in this case: we need to look at the contents ("headers") of the UDP message to figure out which port we mark as related. I think this is not possible from a userspace helper.

The second link is not live -- internal site perhaps?
Comment 46 David Jaša 2014-01-04 18:09:57 EST
Hi, I've used in the past mediatomb (from EPEL or manually backported from fedora) and it used to work for me:
# SSDP for mediatomb
-A INPUT -m state --state NEW -p udp --dport 1900 -j ACCEPT
# allow IGMP for UPnP/SSDP on wlan0
-A INPUT -i wlan0 -p igmp -j ACCEPT

so I guess that iptables has opened data port as a RELATED connection. mediatomb has run as a system service however but that shouldn't matter, should it?
Comment 47 David Jaša 2014-01-04 22:21:36 EST
(In reply to David Jaša from comment #46)
> Hi, I've used in the past mediatomb (from EPEL or manually backported from
> fedora) and it used to work for me:
> # SSDP for mediatomb
> -A INPUT -m state --state NEW -p udp --dport 1900 -j ACCEPT
> # allow IGMP for UPnP/SSDP on wlan0
> -A INPUT -i wlan0 -p igmp -j ACCEPT
>

Scratch that, mediatomb also used a fixed tcp port for HTTP UI which apparently was used for DLNA traffic as well...
Comment 48 Gary Anderson 2014-02-08 16:01:42 EST
I've found a way (good or bad) to get Rygel's served media to been seen by my Roku3.

I'm running Fedora 19. 
I've enabled "Share media through DLNA" and specified my primary interface in the Rygel Preferences dialog. 
I'm using a stock rygel.conf file with its "dynamic port" feature. 
I've added the ssdp service (UDP port 1900) to the firewall and reloaded the firewall.

...finally...

I've had to add a Rich Rule to the firewall, ipv4 accept tcp src 192.168.10.x (address of Roku) dest 192.168.10.y (address of Rygel server)

Now finally the Roku sees and plays all music, pictures and videos.
Comment 49 Ash Hughes 2014-03-08 11:51:06 EST
(In reply to Jussi Kukkonen from comment #45)
> (In reply to Aleksandar Kostadinov from comment #44)
> > What about user-space conntrack helper [1][2]?
> > 
> > [1] https://lkml.org/lkml/2013/5/7/830
> > [2]
> > http://post-office.corp.redhat.com/archives/tech-list/2013-December/msg00151.
> > html
> 
> I'm certainly not an expert on conntrack, but I believe that does not work
> in this case: we need to look at the contents ("headers") of the UDP message
> to figure out which port we mark as related. I think this is not possible
> from a userspace helper.
> 
> The second link is not live -- internal site perhaps?

I've started on a userspace helper for 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 conntrack userspace helpers, not just the kernel helpers.

marc.info/?l=netfilter-devel&m=139429473308767&w=2
Comment 50 Jussi Kukkonen 2014-04-03 05:00:14 EDT
(In reply to Ash Hughes from comment #49)
> I've started on a userspace helper for 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 conntrack
> userspace helpers, not just the kernel helpers.
> 
> marc.info/?l=netfilter-devel&m=139429473308767&w=2

This is cool, thanks. 

I assume "works for me" means it makes client side UPnP apps (like media players) work by allowing all connections to their SSDP port? I believe what I said in comment 45 about session specific services still stands: If we can't hard code the rygel http port, then we have to peek into the UDP messages to figure out the data port, and that's not possible with userspace helpers. Or have I misunderstood something?
Comment 51 Ash Hughes 2014-04-03 12:06:59 EDT
Yes, this patch, now merged, lets systems using firewalld (or similar) act as UPnP clients to find UPnP services. I think what's actually needed for configuring rygel server firewalls might be another, similar, conntrack helper which understands the reply to the M-SEARCH packet. I think this reply is the packet which contains the port of the control point - the port rygel uses - which is dynamically decided by default. 

I think you should be able to peek at the UDP packets in the way you want. My helper can see source and destination ip and ports (header items) as well as the string "M-SEARCH" within the packet, so I don't think this will be a problem.(?) It uses conntracks expect mechanism (we expect replies on this port from different address than the one we sent the search packet to). The expect mechanism asks for a timeout - so the port accepts related connections for a time after the the search was sent. In rygels case, I think that along with a new conntrack module, you could have a long-ish timout and then send out SSDP discovery packets yourself to refresh the firewall - which also allows it to close the port if rygel is stopped. This would mean that rygel depends on conntrackd to do its firewall management, which has its own portability problems. Could rygel pick a default port from the IANA unassigned list  to perhaps fall back on, and then if that fails too, inform the user that they need to pick a different port?

Sorry if I posted in the wrong place initially. I was having my own SSDP problems, which I solved, and this thread pointed me towards the cause of the problem, and therefore the fix. I posted hoping it would be helpful!
Comment 52 Jussi Kukkonen 2014-04-04 07:14:48 EDT
(In reply to Ash Hughes from comment #51)
> I think you should be able to peek at the UDP packets in the way you want.
> My helper can see source and destination ip and ports (header items) as well
> as the string "M-SEARCH" within the packet, so I don't think this will be a
> problem.(?)

Oh, I was under impression that wouldn't be possible. I'll look into that.

> It uses conntracks expect mechanism (we expect replies on this
> port from different address than the one we sent the search packet to). The
> expect mechanism asks for a timeout - so the port accepts related
> connections for a time after the the search was sent. In rygels case, I
> think that along with a new conntrack module, you could have a long-ish
> timout and then send out SSDP discovery packets yourself to refresh the
> firewall - which also allows it to close the port if rygel is stopped.

UPnP services send NOTIFYs periodically so we can look at those and open the specified port for the specified timeout... This is basically a way for any application to open any incoming port they want which sounds a bit wrong though...

Nevertheless your example should make testing this very easy: I'll try to do it next week, we'll see if it's good enough for anyone.

>  This
> would mean that rygel depends on conntrackd to do its firewall management,
> which has its own portability problems. Could rygel pick a default port from
> the IANA unassigned list  to perhaps fall back on, and then if that fails
> too, inform the user that they need to pick a different port?

See comment 39: rygel is logically a per-user service so that is not a perfect solution.

> Sorry if I posted in the wrong place initially. I was having my own SSDP
> problems, which I solved, and this thread pointed me towards the cause of
> the problem, and therefore the fix. I posted hoping it would be helpful!

Info and patch were very useful, thanks!
Comment 53 Bastien Nocera 2014-08-04 13:40:47 EDT
This will be fixed in Fedora 21, with the default firewall (and firewalld) configuration not blocking any non-root ports. See also:
http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html
and also:
http://article.gmane.org/gmane.linux.redhat.fedora.desktop/9883/
Comment 54 Mihkel Vain 2016-05-23 14:09:57 EDT
Hi.

I'm opening this bug again. Did a upgrade to Fedora 24 from v23 yesterday and I thought I'd give rygel a spin. Before I used minidlna. When I stop firewalld service I can browse and play my shared content from my TV and if I start firewalld again, my device does not appear in my TV.
Comment 55 Bastien Nocera 2016-05-23 14:41:06 EDT
(In reply to Mihkel Vain from comment #54)
> Hi.
> 
> I'm opening this bug again. Did a upgrade to Fedora 24 from v23 yesterday
> and I thought I'd give rygel a spin. Before I used minidlna. When I stop
> firewalld service I can browse and play my shared content from my TV and if
> I start firewalld again, my device does not appear in my TV.

Don't reopen bugs 2 years afterwards. Please, file your own bug, this is likely a misconfiguration (and read the blog post to see how we solved the problem as well).