When RealServer is on the opposite side of a firewall from RealPlayers users trying to view its content, certain problems may occur due to the nature of firewalls and RealServer-to-RealPlayer communication.
- For all RealServers, regardless of firewall location
- RealServer is behind a firewall, RealPlayers are outside it
Make your clips available to the widest range of Players by allowing even those behind strict firewalls to receive your content. If your site is visited by RealPlayers users that are unable to receive your content because their firewalls block one or more of the TCP or UDP connections that RealServer requires, you can configure RealServer to send its streams in a manner that their firewall will allow.
Some firewalls allow only HTTP traffic (the sending of Web pages). You can instruct RealServer versions 4.0, 5.0, and G2 to wrap its streams requested by these players in the HTTP format.
To enable this feature, verify that the line HTTPPort 80 (versions 4 and 5) or <Var HTTPPort="8080"/> (version G2) is present in the RealServer configuration file. (In most cases, this line is added to the configuration file during installation.) As long as the Web server and the RealServer are on different machines, or have separate IP addresses, this option is viable. This is called "Smart Networking."
After you have added this line to the RealServer's configuration file and restarted RealServer, any RealPlayer (version 4.0, 5.0, G2, 7, or 8) for which you have chosen AutoConfigure or selected Use HTTP Only in the Preferences dialog box will be able to receive your content.
However, sending clips with HTTP is not as efficient as the TCP and UDP methods.
Note: It is not possible to use Smart Networking with Microsoft Internet Information Server (IIS) version 3.0. Smart Networking does work with IIS version 4.0.
When RealServer is behind a firewall, serving to RealPlayers outside the firewall
If your RealServer is behind a firewall streaming content RealPlayers 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 RealPlayer 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.
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. RealPlayer 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.
Having RealServer and RealPlayer on the same side of a firewall is fine (such as on an intranet). No errors will occur because
of the firewall. However, if the RealPlayers inside the firewall want to access RealServers outside the firewall, you may need
to make some adjustments to the firewall. Likewise, if you are serving content with your RealServer outside the firewall, it's
best to move the RealServer to the perimeter network.