Earlier this chapter noted that IP Filter firewalls restrict network traffic based on IP address and port number. Crystal Enterprise works well with IP Filter firewalls with the proviso that the IP address and TCP port number used by the servers are predetermined. This section discusses a scenario where the Crystal Enterprise WC/Web server and WCS has one IP Filter between the two of them and the WCS is separated from the rest of the Crystal Enterprise servers by a second firewall. In other words, its the common firewall scenario you looked at in the previous section. This is illustrated in Figure 26.5.
Lets look at two distinct parts of communication across the networks: first, the most external portion (that is, between Network C and Network B), and second, the communication between the WCS and the other Crystal Enterprise serversthe internal portion between Network B and Network A (see Figure 26.6).
Any requests of the WC machine would follow the same steps as described in the previous section. Initially, the WC would have to establish a TCP connection to the WCS. The WC would initiate this handshake communication. The IP Filter firewall would certainly stand to convolute this communication:
The network rules of this side of the firewall will quickly determine that the destination IP of this request will have to go through the firewall. Therefore, the network forwards this TCP connection request to the firewall. The firewall then evaluates the information within the requestthe destination port and IP address, as well as the source IP and source port. The firewall must have rules that allow this connection to go throughit must accept requests for the WCSs IP from the WCs IP and the request must be on the specified port. At this point in the request, the firewall will have to allow traffic through it that follows this configuration:
When the WCS receives this request, it must respond to it. It garners the information about where to respond from the information within the request. It takes the Source IP and Port and makes this the destination. Because this is a random port, the firewall must be configured to allow any ports to leave Network B and go to Network C. This is a generally accepted practicestrict port enforcement is done at the bastion host. Therefore, the firewall rules to complete this request should resemble the following:
When the connection request gets through the firewall, the network resolution will determine that the destination is in Network C. The request will hit the Web server/WC. At this point, there is a TCP connection between the two machines, going through the firewall. The WCS will send the WC its IOR and the WC will close this TCP connection.
The IOR contains the IP and port on which the second connection will be made. The port number in the IOR will be one of many values depending on the existence or nonexistence of the -requestport xxxx directive on the WCSs command line. If there is a -requestport, this is the value that will be in the IOR. If there isn , it will be a random port as chosen by the WCSs operating system. Generally, a random port is not acceptable because administrators won enable their firewall rules to accept any ports from a specific IP.
The Crystal Enterprise Administrators Guide suggests that the use of the -requestport option is required with IP Filter firewalls.
When this second connection is made, the -requestport directive should be set to a fixed port number and this port number should be accepted if the IP is from the Web server/Connector machine. This second TCP connection information will look like this:
The firewall will evaluate this request and the port will have to be open. As an example, if the -requestport directive uses port 3333, the firewall rules will have to look like this:
The WCS will respond to this request on whichever port the Web server/WC found to be available. This will be allowed through the firewall because any port is allowed from the internal network to the external. There will then be an established connection between the WCS and the WC, and IP packets will be sent on this channel. The configuration of the firewall rules for an IP Filter firewall between a WCS and WC are summarized in Table 26.1.
IP of WC
IP of WCS
When the WCS is started with the -requestport switch, this port will have to be open going from Network B to Network C for the IP of the WCS.
There are several servers in the Crystal Enterprise environment with which the WCS communicates. It must communicate with the CMS as part of logon/security procedures, while the Cache Server will also be involved in a communication with the WCS for report viewing requests. (Additionally, the WCS will communicate with the Input File Repository Server, where the report objects are maintained when the thumbnail of a report is displayed on the Web page.) Obviously, traffic to each of these servers from the WCS will have to be allowed by the IP Filter firewall (see Figure 26.7).
First and foremost, the WCS will have to communicate with the CMS. The CMS provides the Name Service in the Crystal Enterprise environment. Without this service, the WCS will not be able to communicate with any of the servers. The CMS listens for requests on the port designated, shown in Figure 26.8 under the configuration tab in the Crystal Configuration Manager (the default value for this port is 6400).
Whenever the WCS needs to communicate with the Name Service of the CMS, it does so on port 6400 by default. The first time the WCS has to communicate with the Name Service is when it starts. When the WCS starts, it must register itself with the Name Service as part of its initialization process. This communication occurs on port 6400. A TCP connection occurs between the WCS and CMS for this to happen. The request will have the following information in it:
After the CMS receives this TCP connection request, it responds back to the WCS to complete the initial connection. This connection response contains the following information:
After this initial connection is complete, the CMS sends the WCS its IOR. The WCS then closes the initial connection and establishes a connection to the CMS using the IP and port that is in the IOR. If the CMS is using the -requestport directive, this is the port that the WCS will use to initiate communication with the CMS. This second connection request will contain this information:
The CMS responds to this request to complete the connection. This response contains the following information:
When this connection is complete, the WCS and CMS will hold it open and use it whenever communication between the two is required. From a firewall configuration perspective, two ports are involved in the communication between the CMS and the WCS: first, the port the CMS listens onthis is port 6400 by defaultand second, the port that is established as the main communication channel between these two processesthis should be the value as defined by the -requestport directive. The "rules" for the firewall configuration can be defined as shown in Table 26.2.
When the CMS is started with the -requestport switch, this port will have to be open going from Network B to Network A for the IP of the WCS.
However, this is only one of three servers with which the WCS would need to communicate. Requests to the Input FRS and Cache Server would still need to be allowed through the firewall. The standard practice is when servers need to communicate with one another, they ask the Name Service for a copy of the IOR of the server they need to contact. To communicate with either the Input FRS or the Cache Server, therefore, the WCS needs to ask the CMS for information about the server to which it needs access.
When these servers start, they give the Name Service portion of the CMS a copy of their IOR. As the other servers require access to it, they ask the CMS for a copy of the IOR of the server they need information about. To determine the IOR of a given server, the WCS and CMS collaborate. When the WCS has a copy of the IOR of the particular server, it attempts to make a connection to the server using the information in the IOR. The information in the IOR contains both the IP address and the port to be used for communication and security information. If the -requestport directive is used, the port will be that defined port; otherwise, its a random port. When working with firewalls, the preferred method is to use -requestport so you can control on which port traffic will be allowed in. As a conclusion, therefore, the firewall rules between Network B and Network A would need to be set up as shown in Table 26.3.
IP of WCS
IP of CMS
6400, -requestport for each of the servers (CMS, Input FRS, Cache Server)
The use of NAT within the IP Filtering firewall adds an additional level of complexity, something explored in the next section.
Part I. Crystal Reports Design
Creating and Designing Basic Reports
Selecting and Grouping Data
Filtering, Sorting, and Summarizing Data
Understanding and Implementing Formulas
Implementing Parameters for Dynamic Reporting
Part II. Formatting Crystal Reports
Fundamentals of Report Formatting
Working with Report Sections
Visualizing Your Data with Charts and Maps
Custom Formatting Techniques
Part III. Advanced Crystal Reports Design
Using Cross-Tabs for Summarized Reporting
Using Record Selections and Alerts for Interactive Reporting
Using Subreports and Multi-Pass Reporting
Using Formulas and Custom Functions
Designing Effective Report Templates
Additional Data Sources for Crystal Reports
Multidimensional Reporting Against OLAP Data with Crystal Reports
Part IV. Enterprise Report Design Analytic, Web-based, and Excel Report Design
Introduction to Crystal Repository
Crystal Reports Semantic Layer Business Views
Creating Crystal Analysis Reports
Advanced Crystal Analysis Report Design
Ad-Hoc Application and Excel Plug-in for Ad-Hoc and Analytic Reporting
Part V. Web Report Distribution Using Crystal Enterprise
Introduction to Crystal Enterprise
Using Crystal Enterprise with Web Desktop
Crystal Enterprise Architecture
Planning Considerations When Deploying Crystal Enterprise
Deploying Crystal Enterprise in a Complex Network Environment
Administering and Configuring Crystal Enterprise
Part VI. Customized Report Distribution Using Crystal Reports Components
Java Reporting Components
Crystal Reports .NET Components
COM Reporting Components
Part VII. Customized Report Distribution Using Crystal Enterprise Embedded Edition
Introduction to Crystal Enterprise Embedded Edition
Crystal Enterprise Viewing Reports
Crystal Enterprise Embedded Report Modification and Creation
Part VIII. Customized Report Distribution Using Crystal Enterprise Professional
Introduction to the Crystal Enterprise Professional Object Model
Creating Enterprise Reports Applications with Crystal Enterprise Part I
Creating Enterprise Reporting Applications with Crystal Enterprise Part II
Appendix A. Using Sql Queries In Crystal Reports
Creating Enterprise Reporting Applications with Crystal Enterprise Part II