Re: How to allow Real Player

[Tom Marshall <tommy@home.tig-grr.com>]

[-- Attachment #1: Type: text/plain, Size: 3517 bytes --]

Please note most of the following discussion applies to RTSP in general, not
just RealPlayer.

On Tue, Aug 12, 2003 at 09:56:31PM -0600, Brad Morgan wrote:
> I'm trying to understand how to setup my firewall to allow Real Player.
> Based on the text below, I've written the following rules: 
> 
> ## Allow Real Player
> for i in $LANIPS; do
>   iptables -A FORWARD -p tcp -s $i --dport 554 -j ACCEPT
>   iptables -A FORWARD -p tcp -s $i --dport 7070 -j ACCEPT
> done
> iptables -A FORWARD -p udp --dport 6970:6979 -j ACCEPT
> 
> I limited the number of UDP ports to a much smaller range than they suggest.

The RTSP protocol normally uses TCP port 554.  Port 7070 is for an old
proprietary protocol called PNA that has been deprecated for over 5 years.
You may still run into it occasionally, but hopefully that is rare.

RTSP is a control protocol.  It does the equivalent of the play/pause/stop
buttons.  The actual data can flow either in separate UDP packets (this is
preferred), or interleaved within the same TCP connection as RTSP.

> What I don't understand is the statement "The range of UDP ports, on the
> other hand, carries the incoming stream. These ports begin to carry traffic
> only after RealPlayer and RealServer have performed the authentication
> routine, and should be enabled only for incoming traffic."
> 
> Is the firewall going to know what to do with an incoming packet to one of
> these UDP ports?  If the internal machine initiated the conversation, then
> ESTABLISHED would know what to do, but that would be outgoing traffic which
> the documentation says won't happen.

When using UDP, the server usually starts sending packets to the client
first.  This means that the NAT does not have a chance to create a mapping
between client and server, so it doesn't know where to send the UDP packets. 
Newer clients are getting around this problem with techniques such as STUN
and Symmetric RTP, but most clients don't have this ability.

> Is this another one of those applications that needs a "helper"?  Does one
> exist?  I looked but couldn't find it.

Bingo!  :-)

In order to solve this problem, you need to use an RTSP ALG (helper module). 
I wrote one for the 2.4.21-preX kernels some months ago.  It's not been
updated in some time due to lack of response.  The changes to get the patch
running on the released 2.4.21 kernel are fairly trivial.  You can download
it here:

	http://home.tig-grr.com/rtsp/index.html

Only 2.4.21-preX is listed at the moment.  I plan to update the module at
some point in the near future and support various kernel versions. 
Eventually it would be nice to get the module into the Linux kernel.

> Strange thing is, the user's web cast worked after adding the above rules,
> but capturing the traffic using Ethereal didn't show any UDP traffic at all,
> only TCP and RSTP on 554.  I did however, see realplayer.exe listening on
> UDP port 6970.

Typically, the client will realize after a few seconds that it's not getting
any packets and switch over to TCP mode.  Some of the more intelligent
clients (such as RealONE players) will remember which servers are not
accessible via UDP and they won't attempt UDP from that server again for
some time.  This is may be why you aren't seeing any UDP packets from the
server on any arbitrary request.

-- 
I've finally learned what "upward compatible" means.  It means we get to
keep all our old mistakes.
        -- Dennie van Tassel

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]