Firewalls can inadvertently or deliberately block streaming media presentations, so familiarity with your network's firewalls will help you stream successfully. This chapter may also help you answer questions from users who are experiencing difficulties due to firewall issues.
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 RealServer and the client need to establish two-way communication to stream and receive media content, firewalls may reject a client's attempt to establish this connection, and the client's request for a clip will be rejected by the firewall.
This chapter explains why you cannot serve any content to users on the Internet if your RealServer is behind a firewall, and shows where to move RealServer so that it can serve content while staying within a perimeter network of protected machines.
The next sections discuss the different possible firewall arrangements and illustrate how RealServer 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 Can Affect the User Experience". |
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 RealServer 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 and Characteristics". |
Streaming content to a client-whether via on-demand streaming or any of the live delivery methods- is straightforward, as described in this section.
Issues that clients may have in connecting to on-demand streams are described in "Communicating with Clients".
Clients connect to live broadcasts in the same way they connect to on-demand streams. However, the encoder that supplies RealServer with its live data may not be able to connect to RealServer if a firewall exists between the encoder and RealServer. See "Communicating with Encoders".
Working with receivers that are located on the other side of a firewall requires special consideration, described in Chapter 12, "Splitting Live Presentations".
Multicasts usually take place within an intranet, where broadcasts are not travelling outside a firewall. If a multicast is occurring through a firewall, the firewall must be specially configured to allow multicast traffic.
RealProxy connects to your RealServer just as any other client would. In addition, it uses two TCP connections to store media in the cache.
When a firewall exists between a client and RealServer, 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 RealServer. See the "Streaming Media Over the Firewall Types" table for a list of which firewalls replace the client's address with their own.
Requests by the Server for authentication information (either from the user or the client software) is delivered over the control channel. If a firewall prevents the control channel connection, RealServer cannot authenticate the request and therefore will not deliver it.
If there is a firewall between users and the location where they are to store their content for hosting, they may not be able to send their clips to the Server.
RealServer uses two connections, known as channels, to communicate with clients: one for communication with the client, and one for actual data. The communication 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.
RealServer uses two sets of protocols in transmitting its data.
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 RealServer 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.
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.
The characteristics of TCP that 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.
The quality of the stream received by a client is related to the transport protocol in use.
RealServer uses two main application-layer protocols to communicate with clients: RTSP (Real Time Streaming Protocol) and PNA (Progressive Networks Audio). These protocols work with the 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. A third protocol, HTTP, is used in sending other types of data.
| Control Channel Protocol | Data Channel Protocol |
|---|---|
| RTSP | TCP and UDP, or TCP only |
| PNA | TCP and UDP, or TCP only |
| HTTP | 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.
Firewall security policy stops all traffic, and allows only those services that the firewall administrator has specifically designated. Typically, HTTP traffic and TCP-based traffic that initiates inside the organization is allowed to pass through the firewall.
A client (such as RealPlayer) that tries to request streamed media through such a firewall will initially be rejected by the firewall, because it is attempting to use UDP, which is not allowed by this type of firewall.
The client is aware that it isn't able to establish a connection with the Server using UDP as the default transport protocol. At this point, the client will try alternate protocols for data delivery, such as TCP or HTTP.
Use of HTTP through the firewall is likely to succeed, since most firewalls are configured to allow HTTP traffic.
RealServer can deliver streaming media over HTTP in two unique ways: by wrapping the RTSP or PNA protocol stream with the HTTP protocol, or by downloading the presentation via HTTP. However, neither of these methods provides the best possible user experience.
If a firewall separates any of the RealSystem component software packages that communicate with each other-such as encoders, Servers, or clients- the delivery of data may not be at an optimal rate.
Information in this section applies to administrators of the Server who are interested in the nature of the connection between RealServer and the following RealSystem software:
When no firewall exists between RealServer and the client (such as when they are both in the same internal network), the component software first tries to establish a two-way TCP control connection to RealServer. The Server 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 RealServer when features such as the Play and Stop buttons are activated.
After the initial connection is established, RealServer 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 RealServer.
To optimize playback quality, clients are designed to automatically try different methods of connecting to RealServer to work through common firewall configurations.
The list below shows how the client software determines what protocol it will ask RealServer to use in sending the streamed media over the data channel.
By default, HTTP download is not allowed, because clients obtain the whole clip, rather than a streamed version. To enable HTTP download, add the clip's path to the HTTP Delivery list.
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 Manual for instructions on setting preferences in the client. See http://service.real.com/help/library/index.html. |
If the client is behind a firewall, and is having difficulty accessing your content, there are steps you can take that may improve service.
Once you have determined that your RealServer is in the correct position in relation to your firewall (see "Best Firewall Configurations"), these steps will help:
80 for the HTTP Port (see the instructions in "To ensure that HTTP traffic can get through to your RealServer:").
RealPlayer includes an option to request that all streams be sent in HTTP format. If you do not have a Web server installed on the same computer or IP address as RealServer, you can receive these clients' requests by setting the HTTP Port value to 80. If RealServer is installed on the same computer as a Web server, you have the following options:
80 for HTTP Port. You must use different values, and these different values must be included in any RealServer links that begin with HTTP.
RealServer can communicate with encoders that are behind firewalls, as long as RealServer is located in its network's perimeter network.
When RealServer and the encoding software are on the same side of a firewall, there are no communication difficulties between them.
Different encoder versions use different protocols to connect to RealServer:
|
|
Additional Information |
|---|
| To see the port numbers used by the different encoder versions, refer to "Port Numbers Used by Encoders". |
As in communicating with clients, UDP is the preferred option for communicating with the Server.
UDP is a more robust protocol for real-time communications, and is therefore the preferred method for encoder-to-Server connections. The TCP protocol can be affected by network congestion and disrupt the live session. UDP is more resilient in periods of brief network congestion.
Encoding connections cannot be proxied. Therefore, if the encoder is behind a firewall, you must do one of the following (listed in order of preference):
By default, receivers and RealServers use UDP to communicate. An option is available for them to use TCP instead.
Splitting connections cannot be proxied. Therefore, if the receiver is behind a firewall, you must do one of the following (listed in order of preference):
A RealProxy located behind a firewall is a common scenario. In this respect, a RealServer-to-RealProxy connection behaves like a RealServer-to-client connection, but only two connection types are available:
Options for HTTP delivery, which other component software may use, are not available.
If the firewall prohibits TCP, RealProxy will not be able to proxy streams on behalf of clients.
|
|
Additional Information |
|---|
| Refer to RealProxy Administration Guide for information on configuring RealProxy. See http://service.real.com/help/library/index.html. |
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 RealServer uses to stream content to clients.
The address that appears in the access log of the source RealServer 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 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.)
The source RealServer's access log shows the IP address of the firewall machine, instead of the client's address.
A network administrator configures the firewall to intercept requests for streaming media.
The source RealServer's access log shows the IP address of the firewall machine, instead of the client's address.
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 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 will be deflected off the firewall and never reach the Player that made the request.
RealServer's access log displays the address of the client.
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.
RealServer's access log displays the address of the client.
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.
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.
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. For example, many packet filtering firewalls also allow network address translation, so the IP shown in the RealServer access log is the firewall's, rather than the client's.
The firewall that provides the best experience for RealSystem software users is one that allows streaming media, by allowing a TCP control channel on port 554, and a UDP data channel on a range of ports.
The next best option is a firewall that allows a TCP control channel and a TCP data channel both on port 554. 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.
Finally, nearly all firewalls allow HTTP traffic, which will work for RealServer-to-client connections. However, encoders and receivers will not be able to communicate with RealServer over HTTP.
If your RealServer is behind a firewall streaming content to clients on the other side of the firewall, reconsider its location. A RealServer behind a firewall does not make much sense, for the following reasons: RealServer needs to open TCP connections based on client requests, and most firewalls permit TCP connections only when they are initiated inside the firewall. Also, RealServer needs to open UDP channels on a variety of ports. Here again, most firewalls permit few, if any, UDP connections.
Your content will be completely inaccessible to clients on the Internet if your RealServer is behind a firewall.
The solution is to move the firewall to a perimeter network, sometimes known as a De-Militarized Zone (DMZ). A perimeter network is outside the main internal network, but still secured by the firewall. Client requests for TCP and UDP connections do not pose the security risk here that they do when the RealServer is behind a firewall. Machines in the perimeter network can be set up with a different, more liberal set of security features than is suitable for those on the internal network.
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.
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 addition to the values shown in the table, if receiver is also serving its own content (separate from splitting), it will use all the values in the "Ports Used by RealServer" table.
Ports used by RealProxy are shown below.
In RealProducer Plus versions 6 and later, you can instruct RealProducer Plus to use TCP for the data connection. UDP is the preferred method, as it results in a better user experience, but TCP may be necessary if there is a firewall between the encoder and the Server. If you do opt to use TCP, port 4040 will be used for both the control channel and the data channel.
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.