The nature of communications between Crystal Enterprise components makes configuring your Crystal Enterprise system relatively complex when you separate the application server running your Crystal Enterprise Java SDK (or the WCS) from your Crystal Management Server (CMS) using Network Address Translation (NAT).
In order to service client requests, the application server (or WCS) needs to communicate with Crystal Enterprise servers. To initiate communications with a Crystal Enterprise server, the application server (or WCS) first contacts the directory listing service on the CMS. The CMS responds on a second port with the address and port number of the requested service. The application server (or WCS) then uses this address and port number to communicate directly with the requested service.
If the application server (or WCS) is separated from the CMS and other Crystal Enterprise servers by NAT, we must ensure that whenever a Crystal Enterprise server passes an address across the firewall to the application server (or WCS), it passes a fully qualified domain name (FQDN) that is routable by the firewall.
To configure the CMS, use the following command
-p ort FQDN:6400-r equestport fixed
The
The
Next you must ensure that the application server (or WCS) is able to communicate with the other Crystal Enterprise servers. Because the application server (or WCS) retrieves contact information for these servers from the CMS, you must force all servers which may communicate with the WCS to register an externally routable FQDN and a fixed port number with the CMS directory listing service. Enter the command
on each server. Specify only a FQDN for the command. Do not specify a port number. In the
Now you can configure the firewall rules to recognize and pass the traffic between the application server (or WCS) and the Crystal Enterprise servers behind the firewall.
This does not finish the necessary configuration. Not all communications between Crystal Enterprise components pass through the firewall. Servers behind the firewall communicate with the CMS and with each other. However, once we configure these servers to register an externally routable FQDN with the CMS, the servers try to use these addresses to communicate with one another. Normally these addresses are not routable on the internal network behind the firewall, so these communications attempts will fail.
To work around this issue you must configure the hosts file on each machine to recognize the hostname of every machine running a Crystal Enterprise server behind the firewall. Alternately, you can set up a separate DNS server behind the firewall that recognizes the FQDN and translates them to internal addresses.
In the simplest version of this scenario, all client applications are installed on a single application server in the DMZ. These applications may include the Crystal Enterprise web desktop, the Crystal Management Console (CMC), and your own custom applications. In this case, the application layer must be able to communicate with every Crystal Enterprise server behind the firewall. You must open a port on the firewall for each server.
You may wish to limit the number of ports that you open on your firewall. One way to do this is to place fewer client applications in the DMZ. An client application that supports only report viewing needs to communicate with the:
The CMC must be able to access every Crystal Enterprise server. Therefore, if the application server hosting the CMC is separated from the CMS by a firewall, you must open a port on the firewall for each server.
Click the appropriate link to jump to that section:
| Crystal Decisions http://www.crystaldecisions.com/ Support services http://support.crystaldecisions.com/ |