previous next

Chapter 6: Firewalls

Firewalls may present communications problems to Helix Universal Proxy. This chapter helps you to become familiar with network firewalls to help you use Helix Universal Proxy successfully. It first provides background on firewalls and network protocols. It then recommends ways to work with firewalls to give viewers the best possible streaming media experience. Finally, it lists the communications ports that RealNetworks components use.

How Firewalls Work

A firewall is a software program or device that monitors, and sometimes controls, all transmissions between an organization's internal network and the Internet. However large the network, a firewall is typically deployed on the network's edge to prevent inappropriate access to data behind the firewall. The firewall ensures that all communication in both directions conforms to an organization's security policy.

Firewall technologies are configurable. You can limit communication by direction, IP address, protocol, ports, or numerous other combinations. Firewalls positioned between your Helix Universal Proxy and other computers may cause communication failures if the firewall does not allow for the types of communication Helix Universal Proxy requires. These other computers may be media clients or servers set up as origin transmitters.

If you have access to the firewall, you can configure it to enable the ports, protocols, and addresses that optimize Helix Universal Proxy communication. In some cases, however, your organization's security policy may prevent optimal streaming. For example, firewalls configured to only allow TCP traffic may cause the user to see frequent buffering of clips. User experience of the presentation is compromised; greater latency and startup times affect the time needed to view the clip, and delivery of the clip requires more total bandwidth.

Protocol Layers

A protocol is a language that computers use when communicating over a network. The Transmission Control Protocol/Internet Protocolcommonly called TCP/IP—encompasses a suite of protocols upon which the Internet is built. TCP/IP protocols work on a layering principal, in which each layer is assigned a specific network task.

For communication to occur, a source computer sends a message from its highest network layer to its lowest. The lowest network layer at the source forwards the message over the network. When the message arrives at the destination computer, it must pass through the exact same layers, but in reverse order.

Each network layer uses specific protocols to perform its task. Packets passed down from upper layers are tucked inside lower layer packets. This is called encapsulation. By encapsulating packets, a layer can handle its responsibilities without understanding the preceding layer. Through this layering scheme, a destination layer on one computer receives exactly the same object sent by the corresponding source layer on another computer.

For example, an application such as a Web browser packages data, such as a Web page request made over HTTP, at the application layer, passing it to the lower transport layer. There, the HTTP request packets are bundled into TCP packets that are then delivered to destination Web server. When the Web server receives the source TCP packets, it strips off the TCP shells, and bumps the HTTP message up to the destination computer's application layer. This layer, in turn, delivers to the HTTP-based request to the Web server.

Note: Network layering is a complex topic. This section omits discussion of additional layers required to deliver packets over a network, focusing instead on the transport and application layers, and the protocols relevant to streaming media for each.

Transport-Layer Protocols

All transport-layer protocols transfer data between hosts. The transport-layer protocol in use can greatly affect the quality of the stream received. There are two main transport protocols used on IP networks: TCP and UDP. Helix Universal Proxy utilizes both of these protocols, and the choice of protocol is generally negotiated automatically by the Helix Universal Servers and clients involved.

Transmission Control Protocol (TCP)

Helix Universal Proxy can use TCP in a number of ways. Because TCP offers a single channel for bi-directional communication, Helix Universal Proxy uses it as a control channel to relay commands from clients to Helix Universal Server about passwords and user commands such as pause and fast-forward. The TCP protocol also guarantees delivery of packets, and has built-in congestion control that helps to provide reliable communication.

On the down side, TCP responds slowly to changing network conditions, and creates network overhead through its error checking facility. For this reason, TCP is best suited for delivering low-bandwidth material like passwords or user commands. In some cases, TCP can facilitate communication through a firewall. For example, firewalls that block UDP traffic between Helix Universal Proxy and its clients may permit TCP connections.

User Datagram Protocol (UDP)

Helix Universal Proxy uses UDP packets to deliver data to client software on its data channel. Client software sends UDP-based requests to Helix Universal Proxy (which get relayed to Helix Universal Server) when packets on the data channel have not arrived. Because the transport does not consume as much network overhead, it can deliver packets faster than TCP.

Because video and audio data typically consume large amounts of bandwidth, it makes the most sense to use UDP to deliver streaming media. For this reason, origin Helix Universal Servers use UDP as the default for server-to- proxy communication.

Application-Layer Protocols

Helix Universal Proxy uses three application-layer protocols to deliver streaming media to clients: RTSP, PNA, MMS. The following table summarizes their use.

Application-Layer and Transport-Layer Protocols
Player Software Application
Protocol
Transport Options
RealOne Player, RealPlayer, QuickTime Player RTSP TCP and UDP, or TCP only
Windows Media Player MMS TCP and UDP, or TCP only
RealPlayer 5 and earlier PNA TCP and UDP, or TCP only

Real-Time Streaming Protocol (RTSP)

A standards-based protocol designed for serving multimedia presentations, RTSP is very useful for large-scale broadcasting. Only RTSP can deliver SureStream files with multiple bit-rate encoding. SMIL, RealText, and RealPix also require RTSP. RTSP uses TCP for player control messages, and UDP for video and audio data. RTSP can also use TCP to deliver data, but this is not recommended. Use RTSP with RTSP-compatible players such as RealOne Player, RealPlayer, and QuickTime Player.

Progressive Networks Audio (PNA)

PNA is a proprietary protocol used in earlier RealNetworks client software versions. PNA is supported in the current Helix Universal Proxy for compatibility with older RealNetworks clients (RealPlayer 5 and earlier). PNA uses TCP for player control messages, and UDP for audio data. PNA can also use TCP to deliver data, but this is not recommended.

Note: The PNA protocol uses pnm:// rather than pna:// in the request URL.

Microsoft Media Services (MMS)

The MMS protocol is designed specifically for serving multimedia presentations. Although it is not standards-based, you can use it to broadcast live or on-demand Windows Media clips to Windows Media Player. MMS uses TCP for player control messages, and UDP for video and audio data. MMS can also use TCP to deliver data.

HyperText Transfer Protocol (HTTP)

HTTP is typically used for Web pages. With Helix Universal Proxy, HTTP is used to display Helix Administrator pages and HTML-based documentation.

Packet Formats

All Internet data is delivered in IP packets. But just as TCP or UDP can encapsulate a control protcol for streaming media, IP packets can encapsulate data packets in formats designed to deliver streaming media data. Helix Universal Proxy uses the RDT and RTP packet formats—either of which can be delivered in either TCP or UDP internet protocol.

RealNetworks Data Transport (RDT)

When Helix Universal Proxy communicates to a RealNetworks client such as RealOne Player over RTSP, it uses RDT as the packet format. A proprietary format, RDT allows the use of RealMedia features such as SureStream.

Real-Time Transport Protocol (RTP)

RTP is a standards-based packet format designed as the companion to the RTSP protocol. QuickTime Player, for example, uses RTP as its packet format. Helix Universal Proxy fully supports RTP, and shifts to RTP automatically when streaming to an RTP-based client such as QuickTime Player. RealNetworks clients such as RealOne Player also support RTP, using this format when receiving data from RTSP/RTP servers.

Communicating with Software Behind Firewalls

Information in this section applies to administrators of Helix Universal Proxy who are interested in the nature of the connection between Helix Universal Proxy and other RealNetworks software.

Communicating with Clients Behind Firewalls

Helix Universal Proxy uses two connections, known as channels, to communicate with clients:

Initial Connection Between Helix Universal Server and Client, or Between Helix Universal Proxy and Client

Initial Connection Between Helix Universal Server and Client, or Between Helix Universal Proxy and Client

At the transport layer, most media players, including RealOne Player, can work around situations in which the first communication fails because the player resides behind a firewall that blocks the preferred protocol. The primary strategy involves shifting automatically to protocols and delivery methods that aren't blocked. Typically, the client shifts the control channel to the less efficient TCP, which is less likely to be blocked than UDP.

If the control connection is established, the client then negotiates the data channel.

Data Channel Between Helix Universal Server and Client, or Between Helix Universal Proxy and Client

Data Channel Between Helix Universal Server and Client, or Between Helix Universal Proxy and Client

Optimally, the data channel will use the more efficient UDP transport. If the stream is live, some client software, including RealOne Player, attempts to set up a UDP multicast first. If this method fails, the client next attempts UDP unicast. And if that fails, the client uses the established control channel for data. In short, the client tries to set up the most optimal data delivery method, relying on the control connection as a last resort.

Note: At the application-layer, Helix Universal Proxy connects with RTSP using UDP or if necessary, TCP for data connections. Helix Universal Proxy has no option for HTTP delivery. Thus, if the firewall prohibits RTSP, Helix Universal Proxy will not be able to proxy streams on behalf of clients.

Specific Protocols and Port Settings

The list below shows how the client software determines what protocol it will ask Helix Universal Proxy to use in sending the streamed media over the data channel.

  1. The client attempts to open a control connection, using TCP. It uses port 554 for the RTSP protocol, or port 7070 for the PNA protocol.
  2. Now that a TCP control connection has been established, the client attempts to set up the data channel.
  3. If the request is for on-demand content, the client tries these methods:

    1. First, it tries UDP, in the range of port 6970 through 32000. (Earlier versions of RealPlayer used a smaller range. Consult the "RealPlayer versions 3 through 5 Communication Ports" table.)
    2. If UDP is not allowed, it requests that the data be sent using TCP on the established control channel.

    If the request is for live content, the client tries three connection methods:

    1. First, it tries to use multicast. This is a specialized option not available on many networks. Multicast uses the UDP transport protocol and may use either the RTSP or PNA application-level protocol. Firewalls must be specially configured to allow multicast traffic.
    2. If multicast is not available, the client requests that the material be sent using UDP on ports 6970 through 32000.
    3. If UDP cannot pass through the firewall, the client requests delivery using TCP on the established control channel.

Users can configure clients to always use a particular protocol and port as directed by their firewall administrator. For more information, refer to the online help of your client software for instructions on setting preferences.

Allowing Pull Splitting to Work Through Firewalls

By default, Helix Universal Proxy and Helix Universal Server are set to auto- negotiate the splitting transport, favoring UDP over TCP. Optionally, both products can use TCP exclusively.

To change the protocol for Server-to-Proxy split communication:

  1. In Helix Administrator, click Proxy Setup. Click Splitting.
  2. In the Live Splitting Transport box, select Always Use TCP.
  3. Click Apply.

Working with Multiple IP Addresses

If your firewall expects to allow connections to Helix Universal Servers only from certain IP addresses, make sure that it permits traffic on all the addresses used in the IP Bindings list.

When the machine on which Helix Universal Proxy is running has multiple IP addresses (either multiple Network Interface Cards or virtual addresses), and you use the IP Bindings feature to instruct Helix Universal Proxy to use those addresses, Helix Universal Proxy will make its outgoing connections using the operating system's routing table. Refer to your operating system's TCP/IP documentation for more information.

Firewall Configurations (For Firewall Administrators)

This section describes firewall types, the best way to configure your firewall to permit streaming media, and lists the port numbers used by Helix Universal Proxy.

Firewall Types

Firewalls can be categorized into roughly six types. A particular firewall vendor may combine more than one type into a particular product. The type of firewall in use by your organization will affect the method that Helix Universal Proxy uses to stream content to clients.

The address that appears in the access log of the origin Helix Universal Server or Helix Universal Proxy depends on the client's type of firewall.

A firewall monitors every type of transmission between client software and the Internet, however, this discussion looks only at the firewalls' effects on streaming media.

Application-Level Proxy Firewall

Application-level firewalls first determine if a requested connection between a computer on the internal network and one on the outside is permitted. If the connection is authorized, the firewall mimics the requesting software and sets up the necessary communication links between the two computers. As an intermediary, the firewall can monitor the communication between the two networks and suppress any unauthorized activity.

Because an application-level firewall acts as an intermediary between RealOne Player and Helix Universal Proxy (or between Helix Universal Proxy and Helix Universal Server), the firewall itself must know how to handle the RealOne Player protocols (RTSP and PNA).

The user must configure the client software to contact a proxy or firewall machine. (In RealOne Player, this setting is located under Tools>Preferences> Connection>Proxy.)

Transparent Proxy Firewall

A network administrator configures the firewall to intercept requests for streaming media.

Packet Filter Firewall

Rather than impersonating an application, network-level firewalls examine the packets of information sent at the transport level to determine whether a particular packet should be blocked. Each packet is either forwarded or blocked based on a set of rules defined by the firewall administrator.

A common configuration for network-level-filtering firewalls is to allow all connections initiated by machines inside the firewall, and to restrict or prohibit all connections made by machines outside the firewall. For most programs, this works well since they usually only establish a single outbound TCP connection.

However, RealOne Player and Helix Universal Proxy (or Helix Universal Proxy and Helix Universal Server) maintain two simultaneous connections: a TCP connection for sending commands and a UDP connection to stream the actual media according to the instructions received from TCP. The TCP connection initiated by the player for controlling the connection will work through a packet filter firewall. Since network-level filters block UDP as a matter of course, the UDP stream sent by the Helix Universal Server or by Helix Universal Proxy will be deflected off the firewall and never reach the player that made the request.

Stateful Packet Filtering Firewall

A stateful packet filtering firewall monitors the communication between the client and the Internet to ensure that inbound packets are being sent at the request of a client inside the firewall. Similar to packet filters, it may include additional options that allow more sophisticated actions to be taken with individual packets.

These firewalls should be configured to permit RTSP and PNA traffic.

Network Address Translation Firewall

A network address translation firewall converts the client's internal address to an external address before it forwards the client's requests to Helix Universal Server. Once it receives a request, Helix Universal Server will send its UDP packets directly to the firewall, rather than to the client, and the firewall may not know which client requested the packets. Network address translation is often implemented as part of packet filtering firewalls or stateful packet filtering firewalls.

SOCKS Firewall

Only software with built-in SOCKS support, that must additionally be configured by the user, can send data through a SOCKS firewall; RealOne Player does not include SOCKS support.

In some cases, a user can install a Winsock.dll that supports SOCKS, and configure it to point to the SOCKS firewall.

Summary of Firewall Types

The table below summarizes the six most common firewall types and any special configuration information.

Streaming Media Over the Firewall Types
Client configuration
required?
IP address seen by
the client
IP address seen by the
Server (in access log)
Valid inside addresses
required?
RTSP support required
to get UDP?
RTSP support required
to get TCP?
Application-level proxy Yes Firewall's address Firewall's address No * Yes Yes
Transparent proxy No Server Firewall No* Yes No**
Packet filter No Server Client Yes No No
Stateful packet filtering No Server Client Yes No No
Address translation No Server Firewall No* Yes No
SOCKS Yes Firewall Firewall No* No*** No
* Usually requires compliance with RFC 1597 Address Allocation for Private Internets (http://www.ietf.org/rfc/rfc1597.txt)
** May require special configuration
***Requires SOCKS version 5.0

Some firewalls are actually a mix of the firewall types described in the preceding section.

Depending on the type of firewall and its location, the client address shown in the access log may not reflect the true address of the client. The table below lists the address that will appear in the access log as the requesting client's address.

Address Shown in Access Log
Firewall between client and Helix Universal Proxy Firewall between Helix Universal Proxy and Helix Universal Server
Firewall type Address shown in Helix Universal Proxy's access log Address shown in Helix Universal Proxy's access log Address shown in Helix Universal Server's access log
Application-level proxy Firewall's address Client Firewall's address
Transparent proxy Firewall Client Firewall
Packet filter Client Client Helix Universal Proxy
Stateful packet filtering Client Client Helix Universal Proxy
SOCKS Firewall Client Firewall
Address translation Firewall Client Firewall

Best Firewall Arrangements

The firewall that provides the best experience for RealNetworks software users is one that allows streaming media, by enabling TCP and UDP traffic. Refer to the section "Ports Used by RealNetworks Products" for a complete list of ports that need to be open.

The next best option is a firewall that allows a TCP control channel and a TCP data channel. Your firewall administrator can easily make this change to the firewall. However, the quality of the connections will not be as good with this configuration.

Locating Helix Universal Proxy Near the Firewall

A realistic deployment of Helix Universal Proxy within or near a secure network is to place it inside a network firewall or in a secure perimeter network known as the DMZ, (for de-militarized zone.) In such a deployment, it is typical that clients are not allowed to access the public internet or other non-local networks directly; instead, clients send their requests to Helix Universal Proxy, which is enabled to make and receive Internet connections outside the secure network. In this arrangement, only Helix Universal Proxy is exposed to network traffic beyond the confines of the secure firewall.

The firewall must allow the following types of connections:

Refer to the next section, "Ports Used by RealNetworks Products", for specific information on the ports that are needed.

Ports Used by RealNetworks Products

The following section will help you to decide which ports to open on your firewall. If you do not want to open all the ports listed, refer to the detailed information at http://service.real.com/firewall.

These tables do not cover use of port numbers in multicasting.

Helix Universal Proxy Default Ports

The following tables list the default ports used by Helix Universal Proxy.

Communicating with Media Players, Communicating with a Child Helix Universal Proxy
Activity Port Number Protocol Purpose
Listen on 554 TCP RTSP proxy requests
Listen on 1090 TCP PNA proxy requests
Listen on 1755 TCP MMS proxy requests
Send to 6970-65535 UDP Data channel (port numbers are not configurable)
Send to 1024-5000 UDP MMS media packet delivery

Communicating with Media Servers
Activity Port Number Protocol Purpose
Send to 554 TCP Control channel for RTSP, and splitting cache data requests from Helix Universal Server version 9.0 & later.
Send to, Listen on 3030 TCP or UDP Data and control channel for pull splitting using TCP. Control channel for pull splitting using UDP. (Used with RealSystem Proxy and RealSystem Server version 8.02 and earlier.)
Send to 1755 TCP Control channel for MMS.
Listen on 6970 - 32000 UDP Data channel for inbound UDP.
Send to 7070 TCP Control channel for PNA requests to Helix Universal Server
Send to 7878 TCP Cache requests to Helix Universal Server(Used with RealSystem Proxy and RealSystem Server version 8.02 and earlier.)

Communicating with Helix Administrator
Activity Port Number Protocol Purpose
Send to 9090 TCP Server Monitor traffic
Listen on Admin Port TCP Helix Administrator

Communicating with a Parent Helix Universal Proxy
Activity Port Number Protocol Purpose
Send to 554 TCP Control channel for RTSP requests to parent Helix Universal Proxy
Send to 554 TCP or UDP Data and control channel for pull splitting
Send to 1090 TCP Control channel for PNA requests to Helix Universal Proxy
Send to 7878 TCP Cache requests to Helix Universal Proxy(Used with RealSystem Proxy and RealSystem Server version 8.02 and earlier.)
Listen on 6970-32000 UDP Data channel

Media Player Default Ports

The following table lists the communications ports used by RealOne Player, RealPlayer 6-8, Windows Media Player, and QuickTime Player. In addition to the settings listed below, RealOne Player inherits proxy settings (if they exist) from the default browser, although users can turn off this feature from the RealOne Player Preferences menu.

When Helix Universal Proxy receives a control channel request, it directs the data to the port number specified by the client. RealOne Player and RealPlayer choose UDP for the data channel, and indicate a data channel port number between 6970 and 32000. Windows Media Player also chooses UDP, and indicates a data channel port number between 1024-5000. If the client chooses TCP for the data channel, Helix Universal Proxy uses the same port number for both the control channel and the data channel.

Communicating with a Parent Helix Universal Proxy
Activity Port Number Protocol Purpose
Send to 554 TCP Control channel for RTSP requests to parent Helix Universal Proxy
Send to 554 TCP or UDP Data and control channel for pull splitting
Send to 1090 TCP Control channel for PNA requests to Helix Universal Proxy
Send to 7878 TCP Cache requests to Helix Universal Proxy(Used with RealSystem Proxy and RealSystem Server version 8.02 and earlier.)
Listen on 6970-32000 UDP Data channel

Media Player Ports for Communication with Helix Universal Server or Helix Universal Proxy
Activity Port Number Protocol Purpose
Send to 7070 TCP Control channel for PNA requests (data channel also, if TCP was requested)
Send to 554 TCP Control channel for RTSP requests (data channel also, if TCP was requested)
Send to 1755 TCP or UDP TCP control channel for MMS requests (data channel also, if TCP was requested); UDP resend requests by MMS
Send to, Listen on 6970-32000 UDP Data channel

Versions of RealPlayer earlier than RealPlayer G2, use the following ports.

RealPlayer versions 3 through 5 Communication Ports
Activity Port Number Protocol Purpose
Listen on 6970 - 6999 UDP Data channel (not configurable)

Helix Universal Server Default Ports

The following tables list the default ports that Helix Universal Server uses to communicate with media clients and other servers.

Helix Universal Server Ports for Communicating with Media Players
Activity Port Number Transport Purpose
Listen on 554 TCP Control channel for RTSP requests (data channel also, if TCP was requested)
Listen on 7070 TCP Control channel for PNA requests (data channel also, if TCP was requested)
Listen on 8080 TCP HTTP requests
Send to, Listen on 6970-6999 UDP Data channel (port numbers are not configurable)

Helix Universal Server Ports for Communication with Helix Universal Proxy
Activity Port Number Transport Purpose
Listen on 3030 TCP or UDP Data channel for pull splitting requests (Used with RealSystem Proxy and RealSystem Server version 8.02 and earlier.)
Send to 6970-32000 UDP Data channel (port numbers are not configurable)
Listen on 7802 TCP Helix Universal Proxy requests (Used with RealSystem Proxy and RealSystem Server version 8.02 and earlier.)
Listen on 7878 TCP Helix Universal Proxy requests (Used with RealSystem Proxy and RealSystem Server version 8.02 and earlier.)

Modifying Shared UDP Port Ranges

Helix Universal Proxy and Helix Universal Server establish a UDP channel for client packet acknowledgements and packet resend requests. Certain network and firewall configurations might prevent UDP data from being sent between a client and Helix Universal Proxy, or between Helix Universal Proxy and Helix Universal Server. While network prohibitions of this UDP traffic do not halt RTSP communications and client playback, it does restrict the ability of the proxy and server to respond to packet loss, and might contribute to delivery quality degradation. Thus, Helix Universal Proxy and Helix Universal Server now allow all UDP client-originated traffic to be multiplexed through a limited, shared UDP port range, if this configuration is required by your firewall.

To limit the number of ports used for UDP replies:

  1. In Helix Administrator, click Proxy Setup. Click Ports.
  2. In the UDP Resend Port Range box, enter a minimum range of two ports for each CPU. This feature is blank by default.
  3. Note: The first port value used in this variable must always be an even number.


RealNetworks, Inc. © 2002 RealNetworks, Inc. All rights reserved.
For more information, visit RealNetworks
Click here if the Table of Contents frame is not visible at the left side of your screen.
previous next