[Icecast] NAT and Playlist Question

[Philipp Schafft]

Good afternoon Ken,


On Mon, 2018-04-02 at 09:52 -0700, Inetken wrote:
> Brief backstory, previous admin is gone and the previous server died.  What
> I could gather was it may have been running Icecast.

Things like this sadly happen.


> I setup Icecast on a
> new CentOS 7 server and the server sits behind a firewall.  The links from
> the users web site points to and internal address for internal users and an
> link to an external address.
> 
> I created a listen.pls playlist with the following:
> 
> [playlist]
> NumberOfEntries=1
> File1=http://<INTERNAL IP>:8000/

Generally I suggest against using IP addresses. But see below.


> The website points to this playlist file and it works fine.  However, when
> I use the external link offsite I get an error that it cannot download the
> listen.pls file and won't play the stream.  Should this work as I have it
> configured?  How should I configure Icecast to work behind a NAT firewall
> for internal and external users?


There are several possible optimal setups. All of them have Icecast with
the same configuration in common. For most stations the default Icecast
configuration works fine (with only passwords changed). Most people
break Icecast by setting too many options.
The default configuration uses port 8000. I suggest to keep this.

Next with NAT you need to ensure the port is forwarded. I generally
suggest not use NAT but routed connections. However this requires a
public IP for your server. But it also solves the problem with
internal/external-split.
I strongly recommend against using a reverse proxy. This works but there
are several pitfalls. This should only be done with a professional
around.

The next step is to decide where to split internal and external users.
There are three possibilities:
     A. You can give internal and external users different URLs to your
        stream. This is the most simple solution but does not work if
        people use the same URL from inside and outside your network.
     B. You can have a server that is reachable from both networks and
        knows the client location (within your network or public
        internet) and generate a playlist based on this. This works
        nicely if such infrastructure already exists. Also it gives you
        a stable playlist URL. However if players cache the Playlist
        they still can't move between networks.
     C. You make Icecast accessible from both networks with the same
        URL. This is the preferred method. This can be done by using a
        static and public IP address for your server. Or by using a
        Hostname that resolves differently from your internal network.
        E.g. bind(DNS server) supports "view"s to allow such setups.

Which solution is best depends a bit on the ecosystem your Icecast runs
within. E.g. if there is any of the other systems already and how much
your clients move around.

As you want to run Icecast behind a NATed connection I guess that it's
also bandwidth limited. I suggest to consider this as well. The
bandwidth needed is about: 2*bitrate*listeners. E.g. with 112kbit/s and
32 listeners the required "upload" bandwidth is about 7.2MBit/s.


I hope that this is of help to you. If you need professional business
support feel free to reply to me off-list.


With best regards,


-- 
Philipp Schafft (CEO/Geschäftsführer) 
Telephon: +49.3535 490 17 92

Löwenfelsen UG (haftungsbeschränkt)     Registration number:
Bickinger Straße 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20180403/d855d3d0/attachment.sig>