Firewalls can inadvertently or deliberately block streaming media presentations, so familiarity with your network's firewalls will help you use RealProxy successfully. This chapter will help you configure your firewall for use with RealProxy.
A firewall is a software program or device that monitors, and sometimes controls, all transmissions between an organization's internal network and the Internet. Whether the network consists of a company's local area networks, wide area networks, and the Internet, or an Internet Service Provider, a firewall is typically deployed to prevent inappropriate access to the files, data, or machines of its customers. The firewall's role is to ensure that all communication, in both directions, conforms to the organization's security policies.
Often, firewalls permit one-way outbound access to the Internet. Because RealProxy needs to establish two-way communication with both clients and transmitter RealServers, firewalls can be problematic if they interfere with either of these necessary connections.
The next sections discuss the different possible firewall arrangements and illustrate how RealProxy works with them. This information will be of interest to anyone who wants to know:
More information on firewalls is available from the RealNetworks Web site at http://service.real.com/firewall.
For information on configuring a specific firewall product, consult the firewall software's documentation.
If a Server is behind a firewall, it can only stream content to other users behind the firewall. It cannot stream over the Internet to users on the other side of the firewall.
 |
Additional Information |
|---|
| Read "How Firewalls Affect RealProxy". |
For a Server that is streaming or broadcasting over the Internet, the best location is in the perimeter network, sometimes known as the de-militarized zone (DMZ).
|
|
Additional Information |
|---|
| See "Locating RealProxy Near the Firewall". |
The firewall that provides the best user experience is one that allows RTSP and PNA application-layer traffic, and that allows use of the UDP transport protocol.
|
|
Additional Information |
|---|
| Refer to "Summary of Firewall Types". |
If a firewall separates any of the RealSystem G2 component software packages that communicate with each other—such as clients, RealProxy, and RealServer— the delivery of data may not occur at an optimal rate, or it may not occur at all.
There are three possible locations of firewalls in relation to RealProxy:
The effect of the firewall depends on the location of the firewall. They are described in the following sections.
Ideally, the firewall should allow UDP and TCP traffic to travel from RealProxy to RealPlayer. At a minimum, it must permit TCP connections between the two products. Otherwise, RealPlayer will not receive any streaming media at all.
RealNetworks recommends that RealProxy be deployed on the same side of the network firewall as the clients.
The firewall must permit RealProxy to make outbound TCP connections to at least ports 554 and 7070 so that RealProxy may connect to upstream RealServers.
Other transports and ports are required for specific RealProxy features:
Passthrough mode requires that the firewall allow inbound traffic to ports 6970 through 32000.
SplitterProtocol variable in the configuration file) must be set to use TCP. Transmitter streams arriving at the RealProxy via TCP may result in client rebuffering or greater start-up latency upon client connection.
The firewall must allow inbound traffic to port 3030 for pull splitting to work.
Caching requires that the firewall allow outbound connections on ports 7878 and 7802.
This section explains how firewalls affect certain RealProxy features, and what changes you may need to make in RealProxy for it to work with your firewall. Those features which are unaffected by firewalls are not described.
RealProxy features affected by a firewall that separates RealProxy and clients are:
Issues that clients may have in connecting to presentations are described in "Communicating with Clients Behind Firewalls".
When a firewall exists between a client and RealProxy, the IP address that appears in the access log's client_IP_address field may not be the true client address, and you might not get an accurate idea of exactly which clients are viewing material streamed by your RealProxy. See the "Address Shown in Access Log" table for a list of which firewalls replace the client's or Proxy's address with their own.
If a multicast is occurring through a firewall, the firewall must be specially configured to allow multicast traffic. Consult your firewall documentation for information on enabling multicast traffic.
RealProxy features affected by a firewall that separates RealProxy and a transmitter RealServer are:
RealSystem applications uses two connections, known as "channels," to communicate: one for sending and receiving instructions, and one for actual data. The first channel is known as the "control channel," since it is over this line that RealServer requests and receives passwords, and the client sends instructions such as play, pause, and stop. Media is actually streamed over a separate "data channel".
Both RealServer and RealProxy use two sets of protocols in transmitting data:
RealProxy and RealServer use two application-layer protocols to communicate with clients: RTSP (Real Time Streaming Protocol) and PNA (Progressive Networks Audio). These protocols establish a two-way TCP connection to send commands from the client such as "start" and "pause," and from RealServer to clients for information such as the clips' titles.
| Control Channel Protocol | Data Channel Protocol |
|---|---|
| RTSP | TCP and UDP, or TCP only |
| PNA | TCP and UDP, or TCP only |
As we will see later in this chapter, the single TCP protocol may be used if a firewall does not permit UDP connections that originated outside the firewall.
The quality of the stream received by a client is related to the transport protocol in use.
The TCP protocol guarantees delivery of packets, which is important for control information and error-checking. It has built-in congestion control, but it is slow to respond to changing network conditions. Because TCP is a two-way connection protocol, the client and the Server can communicate about passwords; the user can press pause or fast-forward and the information is sent over the TCP connection. However, verification that each set of instructions reached its intended destination consumes some overhead.
The characteristics of TCP which make it suitable for control information also make it less appropriate for continuous data delivery. The overhead used in TCP is not optimized for the delivery of streaming media.
UDP packets are sent in one direction only. Because the transport does not perform error checking, it can deliver the packets faster than TCP does.
RealProxy and RealServer use TCP to send presentations to the media cache.
Information in this section applies to administrators of RealProxy who are interested in the nature of the connection between RealProxy and other RealSystem software.
When no firewall exists between RealProxy and the client (such as when they are both in the same internal network), the client software first tries to establish a two-way TCP control connection to RealProxy. The Proxy uses this connection initially as a means of sending information to the client about the requested media, such as the name, length, and copyright of the clip. The client uses the connection to send commands to RealProxy when features such as the Play and Stop buttons are activated.
After the initial connection is established, RealProxy then establishes a data channel back to the client. The actual media is sent along this channel, which uses UDP.
This section explains the logic used within the client software as it tries to contact your RealProxy.
To optimize playback quality, clients are designed to automatically try different methods of connecting to RealProxy to work through common firewall configurations.
The list below shows how the client software determines what protocol it will ask RealProxy to use in sending the streamed media over the data channel.
If the request is for on-demand content, the client tries these methods:
If the request is for live content, the client tries three connection methods:
Users can configure RealPlayer to always use a particular protocol and port as directed by their firewall administrator.
|
|
Additional Information |
|---|
| Refer to RealPlayer Plus G2 Manual for instructions on setting preferences in the client. See http://service.real.com/help/library/index.html. |
By default, RealProxy and RealServer use UDP to communicate in pull splitting mode. An option is available for them to use TCP instead.
If your firewall expects to allows connections to transmitter RealServers 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 RealProxy is running has multiple IP addresses (either multiple Network Interface Cards or virtualized addresses), and you use the IP Bindings feature to instruct RealProxy to use those addresses, RealProxy will make its outgoing connections using the operating system's routing table.
Consider the following addresses, which could be listed in the IP Bindings feature (described in "Reserving IP Addresses for RealProxy's Use"):
172.16.0.1
172.16.0.2
If a client connects to RealProxy on address 172.16.0.1, RealProxy will forward the request to the transmitter RealServer using 172.16.0.1. This same address will appear in the transmitter RealServer's access log. Another client that connects on 172.16.0.2 will have its request sent along using 172.16.0.2. The IP address of 172.16.0.2 will appear in the transmitter RealServer's access log.
This section describes firewall types, the best way to configure your firewall to permit streaming media, and lists the port numbers used by RealProxy.
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 RealProxy uses to stream content to clients.
The address that appears in the access log of the transmitter RealProxy depends on the client's type of firewall.
A firewall monitors every type of transmission between client software and the Internet, but this discussion looks only at the firewalls' effects on streaming media.
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 RealPlayer and RealProxy (or between RealProxy and RealServer), the firewall itself must know how to handle the RealPlayer protocols (RTSP and PNA).
The user must configure the client software to contact a proxy or firewall machine. (In RealPlayer, this setting is located under Options>Preferences> Proxy.)
A network administrator configures the firewall to intercept requests for streaming media.
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, RealPlayer and RealProxy (or RealProxy and RealServer) maintain two simultaneous connections: a TCP connection for sending commands and a UDP connection to stream the actual media according to the instructions received via 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 RealServer or by RealProxy will be deflected off the firewall and never reach the Player that made the request.
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.
A network address translation firewall converts the client's internal address to an external address before it forwards the client's requests to RealServer. Once it receives a request, RealServer 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.
Only software with built-in SOCKS support, that must additionally be configured by the user, can send data through a SOCKS firewall; RealPlayer 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.
The table below summarizes the six most common firewall types and any special configuration information.
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.
The firewall that provides the best experience for RealSystem software users is one that allows streaming media, by enabling TCP and UDP traffic. See the "Ports Used by RealProxy" table 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.
A realistic deployment of RealProxy within or near a secure network is to place it inside a network firewall or in a secure perimeter network (sometimes known as a De-Militarized Zone, or DMZ). 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 RealProxy, which is enabled to make and receive Internet connections outside the secure network. In this arrangement, only RealProxy 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 RealSystem", for specific information on the ports that are needed.
Information in these tables will help you decide which ports to open on your firewall. For more detailed information, especially if you do not want to explicitly open all the ports listed, refer to the documentation on the RealNetworks Web site, at http://service.real.com/firewall.
These tables do not cover use of port numbers in multicasting.
Ports used by RealProxy are shown below.
In addition to the settings shown below, RealPlayer inherits proxy settings (if they exist) from the default browser. If they change in the browser, the changes are reflected in RealPlayer. Users can turn off this feature from the RealPlayer Preferences menu.
The ports used in sending requests to RealProxy (usually 1090 and 554) may be different if the client is configured to contact RealProxy through a different method. Refer to Chapter 7, "Firewalls and RealProxy" for information.
Normally, the client software chooses UDP for the data channel, and indicates a port number between 6970 and 6999 on which it will receive the data. RealServer receives the request on port 554 (if requested via RTSP) or port 7070 (if requested via PNA), and directs the data to the port number specified by the client.
If the client software chooses TCP for the data channel, RealServer uses the same port number for both the control channel and the data channel. If the clip was requested using RTSP, both channels will use port 554. If the clip was requested using PNA, both channels will use port 7070.
This table shows the typical values used by RealServer in conjunction with RealProxy.
